On 13.07.2016 16:33, Jäkel, Guido wrote:
Dear André,
thank you for quickly announcing your idea for an workaround. But you right see
the limits, and the more important
impact of disabling the connectors is that it will also disable the traffic to
all the other running applications (and we have a
bunch of it on each of our Tomcats)
In the first instance I want to have a fix for the issue. But nevertheless,
maybe this lead me to a suitable workaround if I
think about it in the background.
Well, here is a little variation of the idea then :
The purpose of the monitoring is normally to verify that the applications are
responding,
right ? (*)
And the fact that the applications are responding, does not depend on the
Connector
through which such requests come in, right ?
So why not define an additional Connector, on a different port, for usage
*only* by the
monitoring system, and disable only /that/ Connector while you are doing your
application
update ?
(*) I mean, if you want to verify that the connection is working, then you can
just do a
"ping" kind of test.
Dear André,
So why? It's because want to modify a complex, multi-staged and well-working
platform as a last resort only. The monitoring does a lot more than to verify
that the applications are running, it's uses a bunch of the data available via
the MBeans for a control dashboard.
It's was my mistake to use the term workaround ...
Guido,
I understand what you are saying, and indeed it would be better to correct the real
problem, rather than looking for (temporary) workarounds.
I was just trying to be pragmatic, and offer some ideas for a possible temporary solution,
in case this stops you from deploying a more recent version of tomcat (and in case this
really bothers you).
But even with my limited knowledge, when I look at the description that you provided, I
have the impression that this may be some very specific problem of your installation.
(I am regularly watching this list, and I do not recall seeing any other mention of a
problem related to yours, over many months).
It may also be one for which providing a simple test case may be somewhat
difficult.
(Because for instance it seems rather timing-dependent; and because we also don't know if
you have complete control over your monitoring/dashboard code).
So it may be some time, before one of the real tomcat developers (which I am not), has a
chance to dig deeper into this and maybe find the problem in tomcat, /if/ it is a problem
in tomcat. (You mentioned yourself something not being really thread-safe; maybe that is
part of the problem).
In that sense, even if the Connector-idea which I mentioned, does indeed block your whole
dashboard, then at least it would block /only/ that dashboard and only during a short
time, and not the rest of the applications.
But it is of course your privilege to pursue whatever path you find best for a solution,
and you can do what you want with my suggestions.
(including putting them in the Gulli with a Dekkel drauf)
Grüsse
André
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
