Logging remote command and origin are very useful. However, I cannot turn on DEBUG logging in production because it is too verbose.
Could I propose one or two minor improvements? Either one works for me:
1) Change the log level of that one message in JGroupsCommandDispatcher.handle() back to INFO.
2) Pass database ID, source address, and remote command in DatabaseEvent. This object is passed from DatabaseClusterImpl.deactivate() to my registered DatabaseClusterListener.deactivated(), but it only contains database ID. I log a message there, but it does not preserve source address and remote command.
Thank you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The reason for this is that in HA-JDBC we send fine/coarse durability commands per invocation. This can easily create a lot of log noise. You can always set the log level threshold for just the net.sf.hajdbc.dispatcher.jgroups category to DEBUG.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If I could ask a related question, is it possible to include the stack trace with the deactivate command? A problem I am trying to solve is notifying the administrator when there is a deactivation within a distributed HA-JDBC cluster. Ideally the deactivated listener could give me these 3 pieces of information so I can send them along in my notification to the admin:
database ID
originating JGroups member (whether local or remote)
root cause (ex: stack trace, requested, etc)
The deactivated listener only includes the database ID, so that is all I can send in my notification. They end up having to look at all Tomcat logs to find a root cause like a stack trace, or if it was requested by a different admin. Logging the command in JGroupsCommandDispatcher means they now only have to look at two Tomcat logs at most. This is already an improvement, but if I can send the originating IP in the notification they only need to look at one Tomcat log. I even have a button in the notification to download the log and display it for them, so turnaround time would be very quick.
The other missing piece in the notification is root cause. If you think it makes sense to pass that in a deactivate command, or even just pass it to the deactivated listener within the local member, that would be another useful improvement.
Thank you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
HA-JDBC 2.0 used to log remote commands as INFO. In 3.0, source address was added to the message but the log level dropped to DEBUG.
Logging remote command and origin are very useful. However, I cannot turn on DEBUG logging in production because it is too verbose.
Could I propose one or two minor improvements? Either one works for me:
1) Change the log level of that one message in JGroupsCommandDispatcher.handle() back to INFO.
2) Pass database ID, source address, and remote command in DatabaseEvent. This object is passed from DatabaseClusterImpl.deactivate() to my registered DatabaseClusterListener.deactivated(), but it only contains database ID. I log a message there, but it does not preserve source address and remote command.
Thank you.
The reason for this is that in HA-JDBC we send fine/coarse durability commands per invocation. This can easily create a lot of log noise. You can always set the log level threshold for just the net.sf.hajdbc.dispatcher.jgroups category to DEBUG.
Thank you for the clarification. I used these settings in Tomcat's logging.properties and I can see the log messages now:
The database ID and originating IP address in the log message are very useful.
If I could ask a related question, is it possible to include the stack trace with the deactivate command? A problem I am trying to solve is notifying the administrator when there is a deactivation within a distributed HA-JDBC cluster. Ideally the deactivated listener could give me these 3 pieces of information so I can send them along in my notification to the admin:
The deactivated listener only includes the database ID, so that is all I can send in my notification. They end up having to look at all Tomcat logs to find a root cause like a stack trace, or if it was requested by a different admin. Logging the command in JGroupsCommandDispatcher means they now only have to look at two Tomcat logs at most. This is already an improvement, but if I can send the originating IP in the notification they only need to look at one Tomcat log. I even have a button in the notification to download the log and display it for them, so turnaround time would be very quick.
The other missing piece in the notification is root cause. If you think it makes sense to pass that in a deactivate command, or even just pass it to the deactivated listener within the local member, that would be another useful improvement.
Thank you.