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:
http://tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html#Cluster_Information
http://tomcat.apache.org/tomcat-9.0-doc/config/cluster.html#SimpleTcpCluster_Attributes
and also in the javadoc for Channel.java
Mitch
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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
