JMS tunneling over HTTP
Michael Gogins
We have had a problem with tunneling JMS publish/subscribe through HTTP and HTTPS
to get through firewalls. The JMS connection drops, and cannot properly be recovered.
The error comes back with a nested exception that has the message:
java.net.ProtocolException: Tunneling result not OK, result: 'DEAD',
id:
'39'
Can anyone tell me what this means?
Or what layer of the protocol stack causes this error? (t3, RMI, JMS, HTTP servlet,
etc.)?
I know that JMS is carried on RMI that is carried on t3 - but whaat layer does
the HTTP translation? I presume it's t3, but I'd like to know.
Or how to fix it?
Jim Brown
1. Which version of WebLogic Server, Service Pack and/or Rolling Patch
are you using?
2. If you are running WLS 6.1 (SP1 or SP2), I would recommend opening a
case with BEA Support and inquiring about a patch for CR061847. This
message is apparently harmless, but will occur because connection
polling is still taking place even after a client connection has been
closed. The GA fix for this CR should appear in Service Pack 3.
3. Can you elaborate on the statement "...and cannot properly be
recovered"?
Regards,
Jim Brown
--
Jim Brown
Developer Relations Engineer
BEA Support
Michael Gogins
Thanks for your prompt reply.
There are 2 scenarios, both occurring when tunneling JMS publish/subscribe messaging
over HTTP or HTTPS on a 56K telephone modem connection. The messages do not go
through a proxy server. The message traffic is between a single "hub" and N "spokes",
and involves a mix of asynchronous notifications, and publishing requests to all
the spokes and waiting for a response from any spoke using a topic session with
a message selector; either the hub or the spoke can cancel any request.
In the first scenario, with WLS 6.1sp1, we don't actually lose the connection.
What happens is that in a few minutes, we find that we when we try to publish
from the client side, we receive the exception:
weblogic.jms.common.JMSException: Error sending message
at weblogic.jms.client.JMSProducer.sendMessage(JMSProducer.java:276)
at weblogic.jms.client.JMSProducer.publish(JMSProducer.java:114)
at com.infinity.fts.net.FtsJMSPublisher.notify(FtsJMSPublisher.java:63)
...
com.infinity.TreasuryNet.provider.ProviderView$14.actionPerformed(ProviderView.java:790)
at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1450)
at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1504)
at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:378)
at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:250)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:216)
at java.awt.Component.processMouseEvent(Component.java:3715)
at java.awt.Component.processEvent(Component.java:3544)
at java.awt.Container.processEvent(Container.java:1164)
at java.awt.Component.dispatchEventImpl(Component.java:2593)
at java.awt.Container.dispatchEventImpl(Container.java:1213)
at java.awt.Component.dispatchEvent(Component.java:2497)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:2451)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:2216)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:2125)
at java.awt.Container.dispatchEventImpl(Container.java:1200)
at java.awt.Window.dispatchEventImpl(Window.java:914)
at java.awt.Component.dispatchEvent(Component.java:2497)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:339)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:131)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:98)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:85)
----------- Linked Exception -----------
java.net.ProtocolException: Tunneling result not OK, result: 'DEAD', id: '39'
at weblogic.rmi.internal.BasicOutboundRequest.sendReceive(BasicOutboundRequest.java:85)
at weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:133)
at weblogic.rmi.internal.ProxyStub.invoke(ProxyStub.java:35)
at $Proxy2.dispatchSyncTranFuture(Unknown Source)
at weblogic.jms.dispatcher.DispatcherWrapperState.dispatchSyncTran(DispatcherWrapperState.java:299)
at weblogic.jms.client.JMSProducer.sendMessage(JMSProducer.java:260)
at weblogic.jms.client.JMSProducer.publish(JMSProducer.java:114)
at com.infinity.fts.net.FtsJMSPublisher.notify(FtsJMSPublisher.java:63)
...
It does NOT work to simply re-try publication after the exception. Therefore,
our code closes all connections and sessions and re-opens them, and then we can
publish again (for a short time, until the whole thing happens again). However,
the consumer(s) from the previous connection are not removed from the JMS server.
In the second scenario, using WLS 6.1sp1 plus the patch for CR061847, the sequence
is exactly the same, except that the consumers from closed connections ARE removed
from the server.
The problem is decidedly NOT HARMLESS, because it occurs every few minutes. In
a production environment with HTTPS connections over telephone modems, this is
an unacceptable burden. Our users will not tolerate waiting for reconnection to
see windows refreshing, etc.
We have opened an issue (296428) and are attempting to re-create the problem in
an example program.
Zach
underlying transport. If the underlying transport reports an error then
JMS fails. Definitely follow up on the support case. You may try posting
in another newsgroup.
_sjz.
"Michael Gogins" <michael...@risk.sungard.com> wrote in message
news:3c3f1117$2...@newsgroups.bea.com...