Status: Open (View Workflow)
Affects Version/s: 3.2.4.Final
Fix Version/s: None
Steps to Reproduce:
Use the servlet transport example from hornetq, but set the connector port to port 80.
Install Apache HTTPD to listen on port 80, with mod_proxy and mod_proxy_http enabled
ProxyPass /messaging/ http://localhost:8080/messaging/
Use transacted JMS sessions to send and receive a bunch of messages at irregular intervals between 5 and 100 seconds.Use the servlet transport example from hornetq, but set the connector port to port 80. Install Apache HTTPD to listen on port 80, with mod_proxy and mod_proxy_http enabled Configure conf.d/proxy_ajp.conf: ProxyPass /messaging/ http://localhost:8080/messaging/ Use transacted JMS sessions to send and receive a bunch of messages at irregular intervals between 5 and 100 seconds.
We want to use HornetQ to connect from hubs worldwide to one central server. The central server is a JBoss Server hidden behind an apache front-end server with mod_proxy as reverse proxy. I tried with with the servlet connector/acceptor in hornetq (which uses HttpTunnelingServlet with HttpTunnelingClientSocketChannel) and deployed it as messaging.war in jboss (HTTP on port 8080, AJP on port 8009). I already upgrade my JBoss Server to use HornetQ 2.2.2 and Netty 3.2.4, and apache to 2.2.19
My client can normally only connect to the apache server, so I configured mod_proxy in the apache server's conf.d/proxy_ajp.conf:
ProxyPass /messaging/ ajp://local.hornetq:8009/messaging/
I can now connect to the server using a client connection with properties useServlet=true, servletPath=messaging/HornetQServlet, host=apache, port=80, and I can send and receive individual messaging using the JMS API very easily.
But as soon as I need to send/receive a couple of messages in a row I get
javax.jms.JMSException: Timed out waiting for response when sending packet 43
Caused by: HornetQException[errorCode=3 message=Timed out waiting for response when sending packet 43]
... 19 more
If I go directly to the jboss server (host=local.hornetq, port=8080), everything keeps running smoothly.
I suspect that HornetQ uses some strange HTTP requests with long running connections and Chunked encoding that gets blocked by mod_proxy.
To start with, I figured out that mod_proxy would inject a Connection: close response header, unless you specify 'KeepAlive On', and would inject a Content-Type header unless you specify 'DefaultType None'.
The exception is triggered when the HttpTunnelingClientSocketChannel receives a response like this:
HTTP/1.1 200 OK
Date: Wed, 01 Jun 2011 16:34:09 GMT
This response was not sent by the HttpTunnelingServlet, but produced by mod_proxy for some unkown reason.
Can you test this setup and document what to configure to make this setup more reliable?