views:

824

answers:

2

Hi. I am using JBoss 4.0.4 GA, which has Tomcat Servlet Container 5.5. I also have IIS 6.0 redirected to this JBoss. (via IIS tomcat connector, which is used as ISAPI filter in IIS). All is working OK, configured the workers as described.

Here is a piece of workers.properties file of the connector:

#
# Defining a worker named ajp13 and of type ajp13
# Note that the name and the type do not have to match.
#
worker.jboss0_ajp13.port=8009
worker.jboss0_ajp13.type=ajp13
worker.jboss0_ajp13.host=localhost
worker.jboss0_ajp13.socket_keepalive=1
worker.jboss0_ajp13.socket_timeout=300

But when connecting to the application via IIS (port 80), for each completed HTTP response for HTTP request, the socket is closed (FIN is sent on the TCP layer). This causes severe slowdowns, since the application is working over WAN. (for each closed socket, another one needed to be established, which takes 500ms).

This is not happening when connecting to JBoss web server directly, and also not happening when connecting to a different virtual directory on the same WebServer instanse of IIS (i.e. Keep-Alive in IIS is also configured).

This happens with the latest version of tomcat IIS connector.

Do you know if there is a bug in the connector, or there is a problem with my configuration?

Thanks in advance,
Henry.

A: 

The socket is probably being closed by IIS. The connection between JBoss and IIS should be irrelevant to the HTTP socket being persisted or not. Ensure that IIS is configured to support persistent HTTP/1.1 sockets.

However, you point out that another virtual directory in IIS does not have the same problem. It could be a problem with the specific virtual directory that is having problems. However, it could also be something in the IIS/Tomcat connector.

To investigate whether it is the IIS/Tomcat connector, try setting

worker.jboss0_ajp13.connection_pool_size=10 worker.jboss0_ajp13.connection_pool_timeout=600

to see if it makes any difference at all. See Tomcat Workers Docs (including the section at the bottom "A sample worker.properties"). See if any of the parameters mentioned there help you out.

Eddie
As I said, when connecting to another virtual directory on IIS (which is not redirected to JBoss), sockets are not closed, and are being reused. Do you still think it's something in IIS?
goryachev
Well, it could be something in the specific virtual directory that is having problems. But if it is the IIS/Tomcat connector, try setting worker.jboss0_ajp13.connection_pool_size=10 to see if it makes any difference at all.
Eddie
Eddie, thanks for the answer, but I have already looked in the documentation of the connector, and examined all the parameters of worker. By default for IIS connection_pool_size=10. Nevertheless, I tried it now hardcoded, and it still doesn't work.
goryachev
As to virtual directory properties, there are none relevant ones. Only at WebSite level, which has been already set, "Enable HTTP Keep-Alives". I guess it's a bug in the connector...
goryachev
Sorry I couldn't help. You should probably log a bug report at the Tomcat Connector web site and see if they can help you at least find out how to gather debugging info.
Eddie
Thanks for sparing you time.
goryachev
+1  A: 

I filed a bug in Bugzilla for tomcat IIS redirector, and this is the answer I've got:

Up until 1.2.27 this was the behaviour of the IIS connector (IIS forces all ISAPI extensions to implement their own HTTP keep alive, and the IIS connector didn't do this).

In 1.2.27 there's experimental, build-time, support for HTTP 1.1 chunked encoding, which should permit persistent connections. (I've been using pretty much the same code in production systems for about 4 years, but it should be considered experimental in the JK codebase until it's been stable for a while).

Grab the -chunked binary from one of the download mirrors and read about how to configure chunked encoding in the 1.2.27 release notes (you have to get the right build, and enable it in your config). You can verify that the connector is using chunked encoding with debug logging on, and a TCP/Wireshark trace should show connections being reused.

If you're still getting closed connections, and the logs show that the connector is attempting (or should be attempting) chunked encoding, then it's probably best to discuss on the users list and then reopen with another Wireshark trace + connector debug log once you're sure there's an issue.

So, what I did:

  1. Put isapi_redirect.dll with chunking support.
  2. Configured the isapi_redirect.properties with the following:

    enable_chunked_encoding=1

  3. Restarted IIS.

goryachev
So ... any luck?
Eddie