<div dir="ltr">Hello, <div><br></div><div>I'm trying to configure an active/active configuration, and experiencing some issues with the Quartz scheduler. The SQL connection seems to timeout quite often and result in many warning messages. I'm also experiencing some errors -- as the timeout closes the connection, some processes are still trying to commit using that stale handler. </div><div><br></div><div>Here are some relevant logs from both midPoint instances in this cluster: <a href="http://pastebin.com/JFjqrLnT">http://pastebin.com/JFjqrLnT</a> <a href="http://pastebin.com/1vy4iYPY">http://pastebin.com/1vy4iYPY</a><br><br>Also here's the relevant portion of my config.xml file: <a href="http://pastebin.com/WbydcCC8">http://pastebin.com/WbydcCC8</a></div><div><br>Following the suggestions in the warnings, I've started to look at autoReconnect propriety of the JDBC connector and applied it to my configs like so:</div><div><br>







<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><jdbcUrl>jdbc:mysql://SERVER:3306/midpoint_dev?autoReconnect=true</jdbcUrl></span></blockquote><div><br></div><div>Since implementing this change, the errors and warnings seem to have disappeared. I will continue to monitor the logs and ensure this actually the case.  </div><div><br></div><div>Reading the mysql docs, I found that this is not recommended as this may cause data inconsistency issues and that stale connection exceptions should be properly caught within the application. Namely:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The use of this feature is not recommended, because it has side effects related to session state and data consistency when applications don't handle SQLExceptions properly, and is only designed to be used when you are unable to configure your application to handle SQLExceptions resulting from dead and stale connections properly.</blockquote><div><br>Do you have any recommended configuration for this scenario? I'd like to move my current production environment in an active active configuration, however as of right now I'm hesitant to do so in order to avoid any data corruption. Especially since it's quite difficult to test for data consistency issues that may arise from using autoReconnect in my dev environment. <br><br>Thanks, </div><div>-F </div><div> </div></div></div>