Working on a variant of McastService

[Greg Turnquist <gr...@gmail.com>]

I ran into issues using McastService on my own setup. Took me awhile to
figure out I was colliding with another instance of tomcat running
elsewhere, sharing the same multicast port. I have started thinking that if
I wrote a different version of McastService that embedded some sort of
logical cluster name, I could detect collisions with other,
differently-named clusters and write some log messages to cause things to
fail faster. In the process, I found that code like
org.apache.catalina.tribes.membership.MessageImpl is highly cohesive. There
are a lot of hard-coded downcasts to the concrete implementation instead of
relying on interfaces.

I was planning to work on a potential patch to submit here that would
involve refactoring things so there are no down casts to MessageImpl and
also possibly removing the static calls as well. With that, it should
become easier to code alternative protocols, including my own that I need
(and hope to contribute back), as well as supporting others that want to
design a pluggable message protocol between their own instances.

If anyone has an opinion on this, please let me know. I'll update this list
when I have a patch to consider.

-- 
Greg Turnquist (Greg.L.Turnquist@gmail.com)

Re: Working on a variant of McastService

[Mark Thomas <ma...@apache.org>]

On 17/12/2012 21:08, Greg Turnquist wrote:
> I ran into issues using McastService on my own setup. Took me awhile to
> figure out I was colliding with another instance of tomcat running
> elsewhere, sharing the same multicast port. I have started thinking that if
> I wrote a different version of McastService that embedded some sort of
> logical cluster name, I could detect collisions with other,
> differently-named clusters and write some log messages to cause things to
> fail faster. In the process, I found that code like
> org.apache.catalina.tribes.membership.MessageImpl is highly cohesive. There
> are a lot of hard-coded downcasts to the concrete implementation instead of
> relying on interfaces.
> 
> I was planning to work on a potential patch to submit here that would
> involve refactoring things so there are no down casts to MessageImpl and
> also possibly removing the static calls as well. With that, it should
> become easier to code alternative protocols, including my own that I need
> (and hope to contribute back), as well as supporting others that want to
> design a pluggable message protocol between their own instances.
> 
> If anyone has an opinion on this, please let me know. I'll update this list
> when I have a patch to consider.

Any changes to Tomcat that make it easier (or possible) to plug-in
custom implementations are welcome. I agree that interfaces should be
used and that they are not always used. I support any efforts to improve
this. I recommend starting with a small patch to ensure you are heading
in an acceptable direction. It would be frustrating to spend a fair
amount of time on a large patch only to see it rejected for some reason.
Several small steps are generally better than one big one.

A new McastService is not the only way to solve the problem you
encountered. As of 7.0.31 the current cluster membership via JMX and I
can think of a couple of further changes that could help debug both the
particular problem you encountered as well as other clustering issues.

1. Add the current cluster membership to the manager status page.

2. Add logging that lists the current cluster membership when a node
joins a cluster. That way, from the logs of any node, you'll have a full
list of current cluster members.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org