If a session holds db locks and is abnormally terminated (no fin/ack), the locks will persist until the db session is closed, typically around 2 hours and 12 minutes with default network tcp_keepalive settings. Abnormally terminated does not include CTRL C or kill -9. The ojdbc6 driver apparently has a shutdown hook thread that closes the connections in graceful shutdowns. The OS apparently closes the connections when processes are killed. Abnormally terminated might include power failure, firewall failures, Out Of Memory, OS/kernel crash, network connection failure, JBoss or other server node failure, etc. This was easily reproduced by creating a process that connected to the db and updated a record but did not commit. While the first process was waiting, a second process with a contending update was started which blocked on the first update. The first clients network cable was then disconnected. The second clients transaction waited for approximately 2 hours until the databa...
It doesn't do ICMP on Windows, it opens TCP echo on port 7. On linux/unix you have to set the suid bit on Java executables to allow it to use ICMP. So that article didn't clearly explain the whole story. When the executable bit is set if a user has permissions to run the program the executable runs at permissions of the owner. If like mine, your java was owned by account with non-root privileges, it still won't be able to access ICMP. You have to set suid bit after changing ownership as the latter clears the suid bit. sudo chown -R root:root sudo chmod 4755 /bin/java Never did get this to work because once the suid bit was set, encountered the following error: libjli.so file not found. I believe this might have to do with suid bit not being set on LD_LIBRARY_PATH references and/or shared libs because it might present a security issue. After discussing with associates realized going this route is probably a bad idea. This would cause all Java programs to run as root presenti...
ActiveMQ supports tunneling JMS over https to transparently traverse firewalls, but the documentation doesn't indicate how to configure it and relevant examples were lacking via google. After hacking for half a day I finally stumbled upon the simple solution. Keep in mind that you will want to create you own keys and certificate. For testing I just used the ones provided in the activemq/conf dir. Simply configure an https transport connector in conf/activemq.xml and pass the keystore, password, and truststore to activemq when started. conf/activemq.xml <amq:transportconnector uri="https://0.0.0.0:61684"> activemq start parameters -Djavax.net.ssl.keyStore=/path/activemq/conf/broker.ks -Djavax.net.ssl.keyStorePassword=password -Djavax.net.ssl.trustStore=/path/activemq/conf/broker.ts import self-signed cert into client jdk keystore cd /path/jdk1.7.0_15/jre/lib/security keytool -import -trustcacerts -file /path/activemq/conf/broker-l...
Comments