If a query exceeds the oracle.jdbc.ReadTimeout without receiving any data, an exception is thrown and the connection is terminated by the Oracle driver on the client. Unfortunately the session will still be queued on the database and continue to wait for locks, hold any current locks, and complete any DML/PL*SQL procedures that are pending on the server-side of the orphaned connection.
If an application, on a another connection, due to ReadTimeout exception, retries DML/PL*SQL which requires locks, those queries will queue behind the initial DML/PL*SQL. This will increase the workload exacerbating the situation. On applications with retries, this can be observed by querying the v$session table or gv$session on RAC and noting new sessions started periodically based on the ReadTimeout interval. The sessions may often have the same SQL_ID and/or SQL_HASH_VALUE.
If stmt.setQueryTimeout(Seconds) is issued and the statement exceeds the timeout, it will attempt to cancel the associated in-p…
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
keytool -import -trustcacerts -file /path/activemq/conf/broker-localhost.cert -alias activemq -keystore cac…