HTTPClientInvoker - Client Lease Feature

[jason.greene]

http://jira.jboss.com/jira/browse/JBREM-317

The client lease feature causes an extra 0-length HTTP post to be sent on connection start, and then periodic "$PING$" posts afterwords.

The problem with this approach is that an HTTP POST is designed for data submissions, so this assumes that the server knows what to do with a $PING$ message, which most likely it won't. So this means that the server will treat this as an error.

The best message to use to "ping" an HTTP server (since it involves no resources) is:
OPTIONS * HTTP/1.1

However, many servers disallow everything but GET, HEAD, and POST. So using HTTP HEAD requests is more practicle.

The other issue is that since HTTP is stateless, "pinging" is not needed, and in some cases its not wanted. HTTP persistent connections (keep-alive) were designed such that the connection is maintained only as long as it's needed, so reasonable timeouts are supposed to apply. By enabling "pinging" you are forcing the unnecessary consumption of server resources, along with adding extra traffic.

So, IMO this behavior should not be enabled by default.

-Jason

[starksm64]

This seems to be an incorrect mapping of the ping notion to the http transport. As you say, a ping enabled config mapped to an http connection is just http1.1 with keep-alive enabled. It does not have to be that the ping notion needs to be disable by default.

[adrian.brock]

Keep alive and ping are not the same thing.

Keep alive uses a ping to maintain a connection such that the client
doesn't have to keep reconnecting. The server is free to drop the connection
at any point. It is just an optimization hint.

The $PING$ is to detect when the server crashes such that the client
can take recovery steps.
e.g. in JMS to invoke the ExceptionListener when the client is doing nothing but
waiting for messages and the server dies.

[adrian.brock]

Conversely, the $PING$ tells the server the client has not died.

[starksm64]

Ok, then your talking about an application level heartbeat message. There needs to be a mapping above the transport layer that routes this to a callback handler. I agree with Jason in that a feature adding to the remoting layer should not simply starting showing up as an application message.

[tom.elrod]

Sorry for being so late to post on this (been on vacation).

There are two issues. The first is the heartbeat, so that the server knows when a client has failed. This is a requirement of the JMS guys and when I added it (version 1.4.0), it was put in as the default behavior (Tim, you'll need to fight for this if you want it to remain that way). For 1.4.1 I have made this configurable, so can turn it off (but still on by default). So this is a short term work around for Jason. Remember, remoting has no insight into if the client is contacting a remoting server or a thirdparty server, so can not guess at if the heartbeat should be turned on or off (without first trying to check with the server or being explicitly told by the client user).

The second issue is how this hearbeat gets translated into the transport call. I agree that it makes more sense to make this a HEAD method type when using HTTP transport. However, this requires a bigger re-work than I have time for in the 1.4.1 release, so pushed off to 1.6.0. If the work around of being able to explicitly turning it off in the client code is not enough in the short term, I need to know.

[timfox]

For JMS we need some way of knowing if the connection has died on the server side, hence the PING.

Orginally I coded this on the application level, but after discussion it was thought the best place to put it was in the remoting layer, see http://www.jboss.com/index.html?module=bb&op=viewtopic&t=71455.

I agree this doesn't make much sense for stateless connections e.g. HTTP.

[starksm64]

This discussion still seems to be mixing two notions of ping, the "is the transport getting msgs to the transport peer", and "is the peer application layer getting the msgs". The latter is why I thought Adrian is talking about, but reading the jira issue I guess the critique was just about keep-alive ala tcp vs a ping msgs between the jboss remoting peers.

What I was talking about in terms of an application level ping was a msg getting to the point of being acknowledged with respect to any reliability guarentees that may exist. Use X may happiliy be sending ping msgs between the jboss remoting peer endpoints, but the msg may not be getting out of a msg queue due to server bugs, resource issues. This type of ping is outside of the scope of the remoting layer.

[jason.greene]

Remember, remoting has no insight into if the client is contacting a remoting server or a thirdparty server, so can not guess at if the heartbeat should be turned on or off (without first trying to check with the server or being explicitly told by the client user).

Yes, adding a heartbeat on top of HTTP assumes 2 things

1. 
   
2. An additional "stateful" reliability guarantee on top of HTTP is desired.
   
3. The server and client know what the ping message is, and how to deal with it
   
   
   This implicitly requires both the client and server to use remoting.
   
   

   
   
   If the work around of being able to explicitly turning it off in the client code is not enough in the short term, I need to know.

   
   
   No, the workaround is fine. Honestly, from the jbossws perspective, we don't really care if we do or don't have to set a particular transport option. I brought this issue up to discuss what the default should be in the interest of future http remoting clients.
   
   So really all of this boils down to what is the primary use case for an http remoting client. If the primary use case is to talk to an http remoting server with stateful guarantee then the current default should remain. If the primary use case is a generic http client invocation api, then IMO it should change.
   
   -Jason

[jason.greene]

This discussion still seems to be mixing two notions of ping, the "is the transport getting msgs to the transport peer", and "is the peer application layer getting the msgs". The latter is why I thought Adrian is talking about, but reading the jira issue I guess the critique was just about keep-alive ala tcp vs a ping msgs between the jboss remoting peers.

To be clear, I am refering to the semantics of normal http use. Normal http is stateless by design, so failure is determined withing the lifespan of a single request. For example, my web browser does not "ping" servers. Web services also falls in the category of normal http use. Adrian is refering to an application specific need of a stateful reliability guarantee that can not be fulfilled with normal use of http. JMS over http has such a need.

-Jason

[jason.greene]

This discussion still seems to be mixing two notions of ping, the "is the transport getting msgs to the transport peer", and "is the peer application layer getting the msgs". The latter is why I thought Adrian is talking about, but reading the jira issue I guess the critique was just about keep-alive ala tcp vs a ping msgs between the jboss remoting peers.

To be clear, I am refering to the semantics of normal http use. Normal http is stateless by design, so failure is determined withing the lifespan of a single request. For example, my web browser does not "ping" servers. Web services also falls in the category of normal http use. Adrian is refering to an application specific need of a stateful reliability guarantee that can not be fulfilled with normal use of http. JMS over http has such a need.

-Jason

Also, I brought up http keep-alive just to demonstrate a case where a heartbeat message is not harmless, and can actually be counter-productive to the design of http. The combination of http keep-alive and a client that sends heartbeat messages can result in an inactive client aggresively holding on to a server connection.

[tom.elrod]

I talked to Tim about this and am going to turn off client ping by default. Will also add ability to add a parameter to the locator uri as a hint that the client should do the ping. Will also change the way the http transport does the ping (HEAD vs POST). Jira issue - JBREM-323

[tom.elrod]

Have committed the changes for the jira issue and added detail comments on the changes and new config in the issue as well.

[timfox]

Has the change been made to turn pinging off by default?

If so, what parameter do i need to add to turn it back on?

[tom.elrod]

http://jira.jboss.com/jira/browse/JBREM-323