internal logging that ordinarily goes to
tomcat.log, etc.
Try here:
https://github.com/grgrzybek/tomcat-slf4j-logback
Brilliant, that's working very well, thank you.
--
Roy McMorran
Systems Administrator
MDI Biological Laboratory
mcmor...@mdibl.org
://tomcat.apache.org/tomcat-6.0-doc/logging.html#Using_Log4j
but for logback?
Many thanks.
--
Roy McMorran
Systems Administrator
MDI Biological Laboratory
mcmor...@mdibl.org
-
To unsubscribe, e-mail: users-unsubscr
On 1/27/11 10:25 AM, Mark Thomas wrote:
On 27/01/2011 15:17, Roy McMorran wrote:
Can anyone point me to a document detailing how to replace Tomcat's
internal logging (via JULI) with logback? Not for access logs, or the
logging output of webapps, but the Tomcat internal logging that
ordinarily
On 9/23/10 8:15 PM, Roy McMorran wrote:
We are observing an odd behavior after upgrading to 6.0.29.
Ordinarily if an exception occurs this will be logged to
catalina.out. When Tomcat is first started (we use jsvc) this is the
case as expected. However if the webapp is redeployed (without
Hi Chuck, thanks for your reply.
On 9/24/10 12:14 AM, Caldarale, Charles R wrote:
From: Roy McMorran [mailto:mcmor...@mdibl.org]
Subject: Errors not logging to catalina.out after redeploy
Ordinarily if an exception occurs this will be logged to catalina.out.
When Tomcat is first started (we
suggestions? Thanks!
--
Roy McMorran
Systems Administrator
MDI Biological Laboratory
mcmor...@mdibl.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
you see in the logs is the concatenation of the session ID
and the worker name. I doubt two servers would generate the same hex
digits for the session. Therefore, your server must be working as
expected, you are just interpreting the logs incorrectly.
-Original Message-
From: Roy McMorran
Mark Thomas wrote:
Nope. The job of that valve is to change the route - exactly what you
are seeing.
Thanks Mark,
Is it the expected behavior then, that the 2nd part of the session ID
changes after a failover, and a new cookie is set?
Thanks,
Roy
--
Roy McMorran
Systems Administrator
Mark Thomas wrote:
Roy McMorran wrote:
Thanks Mark,
Is it the expected behavior then, that the 2nd part of the session ID
changes after a failover, and a new cookie is set?
Yes
Mark
Interesting. I am certain I saw the other behavior (both parts of the
session ID were
Mark Thomas wrote:
Roy McMorran wrote:
Is it the expected behavior then, that the 2nd part of the session ID
changes after a failover, and a new cookie is set?
Yes
OK, please bear with me here, I may be just showing my ignorance with
respect to Tomcat and web applications
Caldarale, Charles R wrote:
From: Roy McMorran [mailto:mcmor...@mdibl.org]
Subject: Re: Session Replication in Cluster
If the session ID changes from ABC123.node1 to ABC123.node2, then
you will start a new session at the browser.
No, you get a new *cookie* at the browser; the session
family members and making a snapshot.
As long as the baby the same everything is alright :)
Thank you János, that is a great analogy! Appreciate your reply.
Cheers,
-r
--
Roy McMorran
Systems Administrator
MDI Biological Laboratory
mcmor...@mdibl.org
FEBA6A8127A69079C79B7A641158CE20.itchy
This is an existing session
After failover:
This is the session id FEBA6A8127A69079C79B7A641158CE20.scratchy
This is an existing session
Thanks,
-r
--
Roy McMorran
Systems Administrator
MDI Biological Laboratory
mcmor...@mdibl.org
on where I went wrong. Thanks and best wishes,
Roy
--
Roy McMorran
Systems Administrator
MDI Biological Laboratory
mcmor...@mdibl.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail
no CPU load on the box.
I've reached a dead end here -I'm hoping someone on the list may have
some ideas. Thanks for any help you may be able to provide.
Cheers,
Roy
--
Roy McMorran
Systems Administrator
MDI Biological Laboratory
[EMAIL PROTECTED
Mark Thomas wrote:
Roy McMorran wrote:
Hello all,
I'm seeing frequent cases where requests sent via mod_jk to Tomcat will
hang indefinitely. The request will never return to Apache and the
client will eventually time out. There are no error messages.
In my test case I run wget against
Mark Thomas wrote:
Roy McMorran wrote:
libtcnative: 1.10
Sorry, should have seen this sooner. Try disabling it or using a newer version.
I'll give it a try but I'm not hopeful. You see I have two systems
exhibiting this hang behavior. The other one (dev) has the latest
Roy McMorran wrote:
Mark Thomas wrote:
Roy McMorran wrote:
libtcnative: 1.10
Sorry, should have seen this sooner. Try disabling it or using a
newer version.
I'll give it a try but I'm not hopeful. You see I have two systems
exhibiting this hang behavior. The other one (dev) has
Roy McMorran wrote:
Despite my misgivings, 1.1.5 seems to have helped. It's run my test
script for about 30 minutes now without problems (previously would
have hung by minute 3).
However!
My dev system (which was already running 1.1.15) still exhibits the
problem. It also has newer versions
19 matches
Mail list logo
