Re: session-replication fails on restart or kill
On 27/08/2013 23:02, Tomcat Random wrote: NP, glad to contribute a little. The FAQ was helpful but it's a little confusing. I'd like to clean it up and add to the part that specifically addresses two boxes two nodes on Linux. Would that be alright? Sure. You'll need to create an account on the wiki and then let us know (replying here is fine) the account name so you can be added to list of contributors - that will enable you to edit stuff. This extra step is necessary to avoid the spam that was created when anyone with an account was allowed to edit the wiki. Mark Thanks, Alec On Tue, Aug 27, 2013 at 5:52 PM, Mark Thomas ma...@apache.org wrote: On 27/08/2013 22:41, Tomcat Random wrote: In a great moment of DUH, I realized I had the expireSessionsOnShutdown to true. Manager className=org.apache.catalina.ha.session.DeltaManager expireSessionsOnShutdown=false notifyListenersOnReplication=true/ All working nicely now. Thanks for posting the solution. It makes the archives much more useful for the next person that finds themselves facing the same issue. Mark On Tue, Aug 27, 2013 at 12:27 PM, Tomcat Random tomcat.ran...@gmail.com wrote: Tomcat 7.0.42 / RHEL 6 / Two physical servers, with one tomcat instance on each server. Physical loadbalancer with sticky sessions. No proxy servers. I've set up session-replication using the delta-manager. I can confirm it works just lovely when the LB switches over from one box to the other. Using a test get/set session value servlet, the manager app reports the primary session value on the box where it was set, and the identical backup value on the other box. So everything appears good there. The problem is if, as a crash test, I stop/restart or kill the tomcat service on the box with the primary session: the backup session on the other box gets removed. So, as you'd imagine, when the LB swaps to the non-dead server the session value is gone. Not so good there. Shouldn't the backup session value remain? Isn't that sort of the whole point. Any ideas? It would seem box 1 and box 2 can communicate enough to create backup session values and detect the death of the other node. Why would the backup session value be lost? Thanks, Alec - 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
Re: buffer expand warning in Tomcat (apache-tomcat-8.0.0-RC1-embed)
On 27/08/2013 03:40, Vince Stewart wrote:
hi all,
thought I would add some progress on this topic.
I have changed my method for reading from the HttpServletRequest object but
the same warning message is thrown for every 8192 bytes read. I no longer
regard my code to be suspect though am happy to be corrected. The
application operates completely normally except for the warning message. The
code I am using to read the input is shown below.
public void doPost(HttpServletRequest httpServletRequest.etc
...other code..
char[] cbuf=new char[8192];
int i=0;
int requestLength=httpServletRequest.getContentLength();
BufferedReader in=httpServletRequest.getReader();
StringBuilder sb=new StringBuilder(requestLength);
while(sb.length()requestLength){
if(in.ready()){
i=in.read(cbuf,0,reqLen);
}
sb.append(cbuf,0,i);
}
in.close();
String message=sb.toString();
//.etc
It looks like there is a possible Tomcat bug but the above code is not
the way to read data from the client as it puts the thread into a tight
loop while it is waiting for more data to arrive.
You'd be better off dropping the call to in.ready() and doing a blocking
read on the socket. The elapsed time should be the same (might even be a
little less) and your CPU consumption during the read when the client is
slow sending data will be significantly lower. If you remove the call to
in.ready(), I'm fairly sure you'll see the warnings disappear.
Ideally, you should look at non-blocking IO as supported by Servlet 3.1
but that might be too big a change as it fundamentally changes how data
is read and written.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Request to be added to the ContributersGroup
Request to be added to the ContributersGroup to be able to append our company to the page Tomcat SupportandTraining since we offer training services on Tomcat. User name: GFUCyrusAG Thank you a lot for your Support! -- Mit freundlichen Grüßen Christine Thon GFU Cyrus AG Am Grauen Stein 27 51105 Köln Tel: 0221/82809-0 Fax: 0221/82809-50 Email:t...@gfu.net Web: http://www.gfu.net Facebook: http://www.facebook.com/gfucyrusag.schulungen Vorstand: Hagen Cyrus, Karsten Kiesel Vorsitzender des Aufsichtsrats: Dirk Weil Amtsgericht Köln HRB 60463 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: buffer expand warning in Tomcat (apache-tomcat-8.0.0-RC1-embed)
On 28/08/2013 09:41, Mark Thomas wrote:
On 27/08/2013 03:40, Vince Stewart wrote:
hi all,
thought I would add some progress on this topic.
I have changed my method for reading from the HttpServletRequest object but
the same warning message is thrown for every 8192 bytes read. I no longer
regard my code to be suspect though am happy to be corrected. The
application operates completely normally except for the warning message. The
code I am using to read the input is shown below.
public void doPost(HttpServletRequest httpServletRequest.etc
...other code..
char[] cbuf=new char[8192];
int i=0;
int requestLength=httpServletRequest.getContentLength();
BufferedReader in=httpServletRequest.getReader();
StringBuilder sb=new StringBuilder(requestLength);
while(sb.length()requestLength){
if(in.ready()){
i=in.read(cbuf,0,reqLen);
}
sb.append(cbuf,0,i);
}
in.close();
String message=sb.toString();
//.etc
It looks like there is a possible Tomcat bug but the above code is not
the way to read data from the client as it puts the thread into a tight
loop while it is waiting for more data to arrive.
I've just cleaned up the code for Tomcat 8.0.x to fix the bug that your
example highlighted. Thanks for such a clear problem statement that made
it very easy to track down the root cause of the issue. The fix will be
in 8.0.0-RC2 onwards.
That said, my comments about there being a better way to do what you are
doing stand.
Mark
You'd be better off dropping the call to in.ready() and doing a blocking
read on the socket. The elapsed time should be the same (might even be a
little less) and your CPU consumption during the read when the client is
slow sending data will be significantly lower. If you remove the call to
in.ready(), I'm fairly sure you'll see the warnings disappear.
Ideally, you should look at non-blocking IO as supported by Servlet 3.1
but that might be too big a change as it fundamentally changes how data
is read and written.
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
Re: Request to be added to the ContributersGroup
On 28/08/2013 10:24, Christine Thon wrote: Request to be added to the ContributersGroup to be able to append our company to the page Tomcat SupportandTraining since we offer training services on Tomcat. User name: GFUCyrusAG Thank you a lot for your Support! Done. Happy editing! Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.0 logging on different platforms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 To whom it may concern, On 8/23/13 4:08 PM, Tomcat Random wrote: I've deleted any reference in logging.properties to the console. However the file rm'd catalina.out file still coming back on restarts. Any ideas? catalina,out is now also reporting java.util.logging.ErrorManager: 4: Unable to create [logs] How are you launching Tomcat? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSHgthAAoJEBzwKT+lPKRYjVYQAJE4tDjLN/wnJ3CgRHyV0h/s 74ngb9um1zsE98vdZupnoLN2uxtEtLvilXOkAmYV0ECAW3/jrkAkhPdcDzp+uoPy IWsuPnQp6ADBgY1Sn/JUzOiuWxua+4kuZru9Lk6NikIPEf1lxQwEAehrRbcyW81K 4/b9ldP4W80hHQuxgHHSVL8WWJpKDAioIT9jSWOZ6S8/MQYW2Gs/AFtmNMooPHmr zNEmm0gE3Y/5lZUmsUjYv//xCdfksmdYmEgo1iH48vNSyJDwxn/S+pxCmbf2gROp 4Lpab3nM4zLn+8FkYqukve22sOKwmOeWJ/28u0zo1DB0eEsnAjr+iUGa1Ff9X9pk Uebc6qQz6QC2MuLf9UsFelj6oCnRAgW/EXKtqE+g1AogplCv7tPnDFQjTo+UMKsh +UuGUJfIMlD04o7ZV+wFzVgeJdQ1FNPxniWoXnFolafUalSXKD9nSfKMwL1FCdtI 9S/DmmpHIzIm3fT8C8GZu7xGypqGfr5siIFFQeUWJR/RdZojAcEjGEzbmBT1nGwv OcaHq8DIcR62t0dMgdceE1ZOmxYBKwWtZYeMyV6oRkCZWzxiYdk45lOE4MalBi3F odsTFvhvEmdnCgEkw7Gu6fjYOPvm4RTLb2nvUg5uYB5Rgu2pMAB+7RxfLcg3PlUY BoUCswXVBKfaBpDqd5KE =d6es -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.0 logging on different platforms
It's a service on RHEL: eg service tomcat start - that does call catalina.sh so I can see where the catalina.out file is being generated. I'll probably just comment that out, although without any console logging in logging.properties it becomes quite light and captures System.err.print messages without any specified logging level. Possibly useful. The Unable to create [logs] problem was the 4host-manager.org.apache.juli.FileHandler without any handler specific properties. -Alec On Wed, Aug 28, 2013 at 10:38 AM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 To whom it may concern, On 8/23/13 4:08 PM, Tomcat Random wrote: I've deleted any reference in logging.properties to the console. However the file rm'd catalina.out file still coming back on restarts. Any ideas? catalina,out is now also reporting java.util.logging.ErrorManager: 4: Unable to create [logs] How are you launching Tomcat? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSHgthAAoJEBzwKT+lPKRYjVYQAJE4tDjLN/wnJ3CgRHyV0h/s 74ngb9um1zsE98vdZupnoLN2uxtEtLvilXOkAmYV0ECAW3/jrkAkhPdcDzp+uoPy IWsuPnQp6ADBgY1Sn/JUzOiuWxua+4kuZru9Lk6NikIPEf1lxQwEAehrRbcyW81K 4/b9ldP4W80hHQuxgHHSVL8WWJpKDAioIT9jSWOZ6S8/MQYW2Gs/AFtmNMooPHmr zNEmm0gE3Y/5lZUmsUjYv//xCdfksmdYmEgo1iH48vNSyJDwxn/S+pxCmbf2gROp 4Lpab3nM4zLn+8FkYqukve22sOKwmOeWJ/28u0zo1DB0eEsnAjr+iUGa1Ff9X9pk Uebc6qQz6QC2MuLf9UsFelj6oCnRAgW/EXKtqE+g1AogplCv7tPnDFQjTo+UMKsh +UuGUJfIMlD04o7ZV+wFzVgeJdQ1FNPxniWoXnFolafUalSXKD9nSfKMwL1FCdtI 9S/DmmpHIzIm3fT8C8GZu7xGypqGfr5siIFFQeUWJR/RdZojAcEjGEzbmBT1nGwv OcaHq8DIcR62t0dMgdceE1ZOmxYBKwWtZYeMyV6oRkCZWzxiYdk45lOE4MalBi3F odsTFvhvEmdnCgEkw7Gu6fjYOPvm4RTLb2nvUg5uYB5Rgu2pMAB+7RxfLcg3PlUY BoUCswXVBKfaBpDqd5KE =d6es -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: buffer expand warning in Tomcat (apache-tomcat-8.0.0-RC1-embed)
Appreciate this a lot Mark.
I'm pretty sure my previous code had a short sleep in each loop but
thankfully, in-coming data rarely exceeds the Servlet InputBuffer size of
8192 so looping is rare.
I have been trying to get to grips with the asynchronous stuff but have not
got it going yet. The concept is very appealing. Thanks for your
contributions.
On Wed, Aug 28, 2013 at 11:00 PM, Mark Thomas ma...@apache.org wrote:
On 28/08/2013 09:41, Mark Thomas wrote:
On 27/08/2013 03:40, Vince Stewart wrote:
hi all,
thought I would add some progress on this topic.
I have changed my method for reading from the HttpServletRequest object
but
the same warning message is thrown for every 8192 bytes read. I no
longer
regard my code to be suspect though am happy to be corrected. The
application operates completely normally except for the warning
message. The
code I am using to read the input is shown below.
public void doPost(HttpServletRequest httpServletRequest.etc
...other code..
char[] cbuf=new char[8192];
int i=0;
int requestLength=httpServletRequest.getContentLength();
BufferedReader in=httpServletRequest.getReader();
StringBuilder sb=new StringBuilder(requestLength);
while(sb.length()requestLength){
if(in.ready()){
i=in.read(cbuf,0,reqLen);
}
sb.append(cbuf,0,i);
}
in.close();
String message=sb.toString();
//.etc
It looks like there is a possible Tomcat bug but the above code is not
the way to read data from the client as it puts the thread into a tight
loop while it is waiting for more data to arrive.
I've just cleaned up the code for Tomcat 8.0.x to fix the bug that your
example highlighted. Thanks for such a clear problem statement that made
it very easy to track down the root cause of the issue. The fix will be
in 8.0.0-RC2 onwards.
That said, my comments about there being a better way to do what you are
doing stand.
Mark
You'd be better off dropping the call to in.ready() and doing a blocking
read on the socket. The elapsed time should be the same (might even be a
little less) and your CPU consumption during the read when the client is
slow sending data will be significantly lower. If you remove the call to
in.ready(), I'm fairly sure you'll see the warnings disappear.
Ideally, you should look at non-blocking IO as supported by Servlet 3.1
but that might be too big a change as it fundamentally changes how data
is read and written.
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
--
Vince Stewart
Re: Tomcat 7 startup issue: ERROR apache.catalina.core.ContainerBase - A child container failed during start
Thanks and Regards,
SG
On Aug 28, 2013, at 4:18 PM, Sabari Gandhi wrote:
Hi,
We are trying to upgrade tomcat 5.5.X to tomcat 7 in our application. I
upgraded tomcat 7.0.39 in my environment (mac) things were working fine. But
when I test this in testing environment (linux , which is also our production
environment) tomcat startup is failing because of the following error.
2013-08-28 15:25:48,921 [11] ERROR apache.catalina.core.ContainerBase - A child
container failed during start
java.lang.InterruptedException
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:979)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281)
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:218)
at java.util.concurrent.FutureTask.get(FutureTask.java:83)
at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:1123)
at
org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:302)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.StandardService.startInternal(StandardService.java:443)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:732)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.startup.Tomcat.start(Tomcat.java:335)
at com.distrobot.mhs.agent.web.HttpServerAgent.wakeup(HttpServerAgent.java:209)
at com.distrobot.mhs.agent.Agent.waitForWakeup(Agent.java:657)
at com.distrobot.mhs.agent.Agent.run(Agent.java:519)
at java.lang.Thread.run(Thread.java:662)
2013-08-28 15:25:48,924 [httpd1] ERROR mhs.agent.Agent.HttpServerAgent -
Stopping httpd1 due to uncaught exception in thread httpd1: Tomcat Startup
Failed [A child container failed during start]
(org.apache.catalina.LifecycleException)
com.kiva.common.utils.FrameworkException: Tomcat Startup Failed
at com.distrobot.mhs.agent.web.HttpServerAgent.wakeup(HttpServerAgent.java:215)
at com.distrobot.mhs.agent.Agent.waitForWakeup(Agent.java:657)
at com.distrobot.mhs.agent.Agent.run(Agent.java:519)
at java.lang.Thread.run(Thread.java:662)
Caused by: org.apache.catalina.LifecycleException: Failed to start component
[StandardServer[-1]]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
at org.apache.catalina.startup.Tomcat.start(Tomcat.java:335)
at com.distrobot.mhs.agent.web.HttpServerAgent.wakeup(HttpServerAgent.java:209)
... 3 more
Caused by: org.apache.catalina.LifecycleException: Failed to start component
[StandardService[Tomcat]]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
at
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:732)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
... 5 more
Caused by: org.apache.catalina.LifecycleException: Failed to start component
[StandardEngine[mhsEngine]]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
at
org.apache.catalina.core.StandardService.startInternal(StandardService.java:443)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
... 7 more
Caused by: org.apache.catalina.LifecycleException: A child container failed
during start
at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:1131)
at
org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:302)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
... 9 more
We use the following code to start up the tomcat in our application
(HttpServerAgent.java) and it is failing when tomcat.start() is called.Any
help is greatly appreciated.
@Override
public void wakeup() {
super.wakeup();
log.info(Starting Embedded Tomcat);
subHandler = new HttpSubscriberHandler(this, servletContext);
Integer updateInterval = MiscellaneousProperty.WEB_PUBSUB_UPDATE_INTERVAL_MS
.asInteger();
updateInterval = (updateInterval == null
|| updateInterval.intValue() == 0 ? PERIOD_IN_MS
: updateInterval);
schedule(subHandler, DELAY_IN_SEC, updateInterval);
try {
if (tomcat != null) {
tomcat.start();
} else {
log.debug(tomcat is null, init() was not called, cannot start.);
}
} catch (LifecycleException e) {
tomcat = null;
throw new FrameworkException(Tomcat Startup Failed, e);
}
}
Thanks and Regards,
Sabari
