-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[AMQ-9447] Added Logic to check underlying transport connector limits #1194
base: main
Are you sure you want to change the base?
Conversation
This first step checking the transports looks good to me. I would also check the storage service. |
Ideally the above mentioned code for JDBC Persistence check will work, with the appropriate imports. |
For JDBC yes, but no test on KahaDB. We can check the system usage for instance to see if the filesystem is not almost full. |
It seems we already have a check for File system usage. |
if(tc.getServer() instanceof TcpTransportServer) { | ||
int connectionUsage = (int) (((TcpTransportServer)tc.getServer()).getCurrentTransportCount().get() * 100 ) / ((TcpTransportServer)tc.getServer()).getMaximumConnections(); | ||
if(((TcpTransportServer)tc.getServer()).getCurrentTransportCount().get() >= ((TcpTransportServer)tc.getServer()).getMaximumConnections()) { | ||
String message = "Exceeded the maximum number of allowed client connections: " + ((TcpTransportServer)tc.getServer()).getMaximumConnections(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This check can’t happen since the connector will close a connection when it reaches the limit. An exceeded count isn’t possible.
I think this branch of logic should just be removed and simply go with the limit check
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree, just the limit is enough.
We can relay on the existing metrics for that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add a quick unit test
We have a check on the system usage, but not on the cursor. It's not super critical. |
Sure, Let me work on that |
Have Added the same, Please have a look. |
(Re-Opened)
Hello Team,
With Regards to Transport Connector, Have added a check based on the connection count.
Also in the ticket, With regards to JDBC Persistence Check, We may need to have JDBC persistence associated classes in activemq-broker,jar, Post that we can have a logic something like following:
if (brokerService != null && brokerService.getPersistenceAdapter() != null && brokerService.getPersistenceAdapter() instanceof JDBCPersistenceAdapter ) { JDBCPersistenceAdapter jdbcAdapter = (JDBCPersistenceAdapter) brokerService.getPersistenceAdapter(); String message = "Issue with Persistence layer"; try { ResultSet rs = null; Statement stmt = jdbcAdapter.getDataSource().getConnection().createStatement(); rs = stmt.executeQuery("SELECT 1"); String message = if(rs.next()) if(rs.getInt(1)!=1) answer.add(new HealthStatus("org.apache.activemq.store.jdbc.JDBCPersistenceAdapterIssue", "ERROR", message, jdbcAdapter.toString())); } catch(Exception e) { answer.add(new HealthStatus("org.apache.activemq.store.jdbc.JDBCPersistenceAdapterIssue", "ERROR", message, jdbcAdapter.toString())); } }
Ive Tested the above and it works as expected. But again that would require whole jdbc persistence adapter code.