tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Cluster session replication performance
Date Wed, 12 Sep 2018 16:37:04 GMT
Hash: SHA256


On 9/12/18 12:01 PM, Mitch Claborn wrote:
> Thanks Mark. I changed to channelSendOptions="2" and the failure
> rate of my health check program has dropped significantly, down to
> 1 - 2 per 24 hours.
> I did quite a bit of reading in the doc before posting this, but
> your explanation of the options is much better than the doc.  I
> suggest that the doc be updated with your explanation below. I
> would put it in the following locations: 
> and also in the javadoc for

Would you care to submit a documentation patch/PR?

Get your name in the ChangeLog and you get the text that makes the
most sense to you :)

- -chris

> On 09/10/2018 03:15 PM, Mark Thomas wrote:
>> On 10/09/18 17:33, Mitch Claborn wrote:
>>> Further information and questions.
>>> I created my own interceptor based on ThroughputInterceptor so
>>> that I could log the timing of specific sessions to correlate
>>> them with the failures in my health check program.  I was
>>> surprised to find that in those instances where the health
>>> check reported a failure, the interceptor reported that the
>>> session send was accomplished in < 5 ms, while the health check
>>> app is waiting a full 1000 ms between calls to the different
>>> tomcat instances. So now I'm more confused than ever.
>>> Anyone have any ideas?
>>> In a ChannelInterceptor, does when
>>> getNext().sendMessage(destination, msg, payload) returns, does
>>> that mean that the message has been sent AND received by the
>>> recipient member, or does that only indicate a send?
>> You are using: channelSendOptions="8"
>> That means that, as far as the sender is concerned, the message
>> is sent as soon as it has been placed in the queue on the sender
>> for transmission to the other nodes.
>> If you use async sending, the options to enable ACKS don't offer
>> very much - if anything.
>> If you configure channelSendOptions="2" the the sender will block
>> the completion of the current request until all of the receiving
>> nodes have acknowledged that they have received the message.
>> If you configure channelSendOptions="6" the the sender will block
>> the completion of the current request until all of the receiving
>> nodes have acknowledged that they have received and processed the
>> message.
>> There is a trade-off here between throughput on the sender vs 
>> reliability of replication if the sender fails.
>> Mark
>> ---------------------------------------------------------------------
To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
To unsubscribe, e-mail:
> For additional commands, e-mail:
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message