Affects Version/s: None
Fix Version/s: 4.2.0-fuse-02-00
Similar Issues:Show 10 results
ESB-925 JDBCLock slave fails when using derby ESB-386 [Servicemix4] Support container level locking for master/slave deployments ESB-446 [Servicemix4] Provide default jdbc lock impl for master/slave deployments ESB-1143 OracleJDBCLock Error when testing Lock to Database - filling UNDO segment? ESB-1084 JDBC failover not working as documented. ESB-1070 JDBC failover not working as documented. ESB-821 FUSE ESB 4 Failover does not work with PostgreSQL and Oracle ESB-475 Cannot start slave on Windows ESB-1207 Hang in JMS flow when failover is used and the broker is slow. ESB-984 Possible ESB console hang during shutdown
Possible hang with slave instances of the ESB when using Oracle JDBC lock.
If we start up the master and slave as normal, then try to stop the slave, it does not release its attempted JDBC lock, and therefore hangs during shutdown. If we then stop the master, the slave throws an error and finally exits.
It's not a major problem, as (1) it's not something we would need to do often, (2) it does not affect the master, and (3) we can work around it by forcefully killing the slave. However it looks ugly, and forceful shutdowns are never a good thing, so if there's a quick fix you can do before tonight's build, please try.
Reproducing the problem is fairly easy, once you have Oracle installed...
- download the new FUSE ESB installer from http://repo.fusesource.com/maven2/org/apache/servicemix/apache-servicemix/4.1.0-psc-01-01RC1
- install two instances (master and slave) of FUSE ESB onto one host
- edit the slave's configuration as follows:
- replace all occurrances of "61616" with "61617"
- replace all occurrances of "default" with "slave"
- add JDBC lock configuration to both instances:
- start the master
- start the slave
- stop the slave
- stop the master
- the slave now exits, with the following exception:
- the slave's log file shows it shutting down and unregistering various bundles, then hanging until the master exits, at which point it prints just two additional lines of logging before exiting: