I've tried to replicate the problem with a simple servlet. outside of
our MVC architecture (controller). and seams like I can't.
I've put traces in our controller on the doPost method writing the
request parameter to the console.
When the 2nd node is shutdown, they request params become nulls! even if
the same Post is done from a local static webpage.
I've been trying to find out why for hours. but seams like I'm getting a
dead-end soon.
any ideas where I could look? fresh ideas would help! :)
Jean-Philippe B�langer
CGI
Filip Hanik wrote:
>interesting, never seen that, let me take a look. I have an automated test
>that I run to check replication integrity.
>since you get this everytime, it shouldn't be a problem for me to do
>reproduce this.
>do you by any chance have the test program you have and would email it to
>me?
>Filip
>
>-----Original Message-----
>From: jean-philippe.belanger@(protected)
>[mailto:jean-philippe.belanger@(protected)]
>Sent: Monday, January 12, 2004 11:56 AM
>To: Tomcat Users List
>Subject: Re: WAS: tomcat 5.0.16 Replication
>
>
>I understand that. Here more info...
>
>I make a servlet request that does this:
>while ( i < 25 ) {
> if ( request.getParameters("xxx") == null ) {
> System.out.println("param is null");
> }
> Thread.currentThread().sleep(1000);
> i++
>}
>
>I then send a couple of request with param xxx=123 at 1 secs interval.
>(those request are all made to the same server ie: web1)
>Once a couple of them are sent I shutdown web2.
>As soon as the "INFO: Received member
>disappeared:
org.apache.catalina.cluster.mcast.McastMember[tcp://10.1
>28.29.66:4001,10.128.29.66,4001,
>alive=6576]" message is received my log gets flooded with param is null
>
>
>Jean-Philippe B�langer
>CGI
>
>
>
>Filip Hanik wrote:
>
>
>
>>the way the login is done, is that a request is being saved in the session
>>(in a session note, and that is not replicated).
>>So for a login, you must hit the same server twice in a row. Otherwise you
>>will see NULL in your request parameters. Also in this release, the
>>principal is not being replicated, I am working on that right now
>>
>>Filip
>>
>>-----Original Message-----
>>From: jean-philippe.belanger@(protected)
>>[mailto:jean-philippe.belanger@(protected)]
>>Sent: Monday, January 12, 2004 11:29 AM
>>To: Tomcat Users List
>>Subject: Re: WAS: tomcat 5.0.16 Replication
>>
>>
>>Been working on testing the new modules and came across something weird.
>>Wondering if you got any idea on the cause/problem while I continue
>>investigating
>>
>>Scenario:
>>- one web page login in a user. receive 3 parameters (user, password and
>>community)
>>- To be able to replicate the problem I had to put a sleep on 25 secs in
>>code.
>>- Post one request each second or so and after a couple of them, shudown
>>one tomcat and restart it. (stop/start sequence)
>>- A couple of request will start pourring the result, but after some..
>>when tomcat that got shutdown is restarting, the request parameters
>>becomes NULL.
>>
>>As if the replication code was killing my request objects or resetting
>>my parameters on those requests. Any thought on what it could be?
>>I even had session mix-up once. when restarting a tomcat a user was
>>logging in and was assigned a session from another user that never
>>logged on from his station (that session was idle for more than 10 hours
>>too).
>>
>>Just trying to pinpoint where the problem could be. Any pointer would help.
>>
>>Thanks
>>
>>Jean-Philippe B�langer
>>CGI
>>
>>
>>Filip Hanik wrote:
>>
>>
>>
>>
>>
>>>Steve and Jean-Philippe,
>>>I've been working on some more replication stuff and made a major change
>>>that I think you might want to use.
>>>I have added a third configuration to the parameter replicationMode,
>>>
>>>replicationMode="pooled"
>>>
>>>With this setting it still is synchronized replication, but uses a pool of
>>>sockets to replicate the data.
>>>It improves performance a lot. Try it out, and let me know how it
>>>
>>>
>works for
>
>
>>>you
>>>You will notice the improvement under load.
>>>
>>>of course, get latest from cvs first
>>>
>>>Filip
>>>
>>>-----Original Message-----
>>>From: Steve Nelson [mailto:Steve.Nelson@(protected)]
>>>Sent: Friday, January 09, 2004 12:05 PM
>>>To: 'Tomcat Users List'
>>>Subject: RE: tomcat 5.0.16 Replication
>>>
>>>
>>>
>>>
>>>Hrmmm, perhaps I should reboot using the non-SMP kernel and try it. I'll
>>>have to do that when I get back to the servers.
>>>
>>>
>>>-----Original Message-----
>>>From: Steve Nelson [mailto:Steve.Nelson@(protected)]
>>>Sent: Friday, January 09, 2004 2:04 PM
>>>To: 'Tomcat Users List'
>>>Subject: RE: tomcat 5.0.16 Replication
>>>
>>>
>>>uname -a
>>>machine #1) Linux draco 2.4.20-8smp #1 SMP Thu Mar 13 17:45:54 EST
>>>
>>>
>>>
>>>
>>2003 i686
>>
>>
>>
>>
>>>i686 i386 GNU/Linux
>>>machine #2) Linux scorpio 2.4.20-8smp #1 SMP Thu Mar 13 17:45:54 EST 2003
>>>i686 i686 i386 GNU/Linux
>>>
>>>
>>>java -version:
>>>java version "1.4.2_03"
>>>Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02)
>>>Java HotSpot(TM) Client VM (build 1.4.2_03-b02, mixed mode)
>>>
>>>same on both
>>>
>>>
>>>-----Original Message-----
>>>From: Filip Hanik [mailto:devlists@(protected)]
>>>Sent: Friday, January 09, 2004 1:56 PM
>>>To: Tomcat Users List
>>>Subject: RE: tomcat 5.0.16 Replication
>>>
>>>
>>>[root@(protected)
>>>Linux rh9 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 i686 i686 i386
>>>
>>>
>GNU/Linux
>
>
>>>[root@(protected)
>>>java version "1.4.2_03"
>>>Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02)
>>>Java HotSpot(TM) Client VM (build 1.4.2_03-b02, mixed mode)
>>>
>>>
>>>-----Original Message-----
>>>From: Steve Nelson [mailto:Steve.Nelson@(protected)]
>>>Sent: Friday, January 09, 2004 11:05 AM
>>>To: 'Tomcat Users List'
>>>Subject: RE: tomcat 5.0.16 Replication
>>>
>>>
>>>sun JDK 1.4.2 for Linux
>>>Kernel 2.4.20-8smp
>>>Tomcat 5.0.16 with catalina-cluster.jar from CVS head
>>>
>>>Hrmmm....are yours SMP servers? Could be something odd with synch
>>>
>>>
>>>
>>>
>>if that is
>>
>>
>>
>>
>>>the case.
>>>
>>>
>>>-----Original Message-----
>>>From: Filip Hanik [mailto:devlists@(protected)]
>>>Sent: Friday, January 09, 2004 1:01 PM
>>>To: Tomcat Users List
>>>Subject: RE: tomcat 5.0.16 Replication
>>>
>>>
>>>interesting, mine doesn't work at all unless I set the LD_ASSUME_KERNEL
>>>
>>>what VM (version and name) are you using?
>>>
>>>Filip
>>>
>>>-----Original Message-----
>>>From: Steve Nelson [mailto:Steve.Nelson@(protected)]
>>>Sent: Friday, January 09, 2004 10:59 AM
>>>To: 'Tomcat Users List'
>>>Subject: RE: tomcat 5.0.16 Replication
>>>
>>>
>>>
>>>Now that's really very strange. I am running RH9 and everything
>>>
>>>
>seems to go
>
>
>>>through just fine.
>>>
>>>
>>>-----Original Message-----
>>>From: jean-philippe.belanger@(protected)
>>>[mailto:jean-philippe.belanger@(protected)]
>>>Sent: Friday, January 09, 2004 12:56 PM
>>>To: Tomcat Users List
>>>Subject: Re: tomcat 5.0.16 Replication
>>>
>>>
>>>The replication message ACK never get back to the sender.
>>>So my webpages never loads without that flag.
>>>
>>>I think it is only needed under REDHAT 9.
>>>
>>>Jean-Philippe B�langer
>>>
>>>Steve Nelson wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>I don't seem to need the ld_assume_kernel thing. What are the
>>>>
>>>>
>>>>
>>>>
>>symptoms when
>>
>>
>>
>>
>>>>it is required?
>>>>
>>>>
>>>>-----Original Message-----
>>>>From: jean-philippe.belanger@(protected)
>>>>[mailto:jean-philippe.belanger@(protected)]
>>>>Sent: Friday, January 09, 2004 12:33 PM
>>>>To: Tomcat Users List
>>>>Subject: Re: tomcat 5.0.16 Replication
>>>>
>>>>
>>>>Just tried the CVS head and everything works with any CPU going crazy!
>>>>only if ld_assume_kernel is set to 2.4
>>>>
>>>>One more question for you Filip, is the useDirtyFlag working at all? It
>>>>seams like even if it's set to true, the whole session gets replicated
>>>>after each request. :(
>>>>
>>>>Jean-Philippe
>>>>
>>>>jean-philippe.belanger@(protected):
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Hurray for Fillip! :)
>>>>>
>>>>>I'll get the CVS head for the module today and test this out.
>>>>>Happy to see that it got fixed that quickly!
>>>>>
>>>>>Thanks again and I'll let you know how it goes
>>>>>
>>>>>Jean-Philippe
>>>>>
>>>>>Filip Hanik wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Jean-Philippe and Steve,
>>>>>>I fixed the bug, and tried replication on RH9. Immediately it didn't
>>>>>>work.
>>>>>>The problem is that when RH9 tries to write the ACK back to the NIO
>>>>>>socket,
>>>>>>it never reaches the other node. and times out after a long time.
>>>>>>
>>>>>>I set LD_ASSUME_KERNEL=2.4 and it started to work
>>>>>>
>>>>>>Filip
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Filip Hanik [mailto:devlists@(protected)]
>>>>>>Sent: Thursday, January 08, 2004 6:43 PM
>>>>>>To: Tomcat Users List
>>>>>>Subject: RE: tomcat 5.0.16 Replication
>>>>>>
>>>>>>
>>>>>>ok guys,
>>>>>>good news. The 100% cpu is totally my fault. I messed up on that one.
>>>>>>I was registering OP_WRITE as an interest
>>>>>>this is not good :)
>>>>>>checking in the working code in 15 min, some more regression tests
>>>>>>Filip
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Filip Hanik [mailto:devlists@(protected)]
>>>>>>Sent: Thursday, January 08, 2004 2:54 PM
>>>>>>To: Tomcat Users List
>>>>>>Subject: RE: tomcat 5.0.16 Replication
>>>>>>
>>>>>>
>>>>>>another code change was, that I am now accepting keys for OP_READ and
>>>>>>OP_WRITE. before it was only OP_READ,
>>>>>>but for synchronous replication I need both.
>>>>>>
>>>>>>this is good info, I just got RH9 installed. will be trying it out
>>>>>>this and
>>>>>>next week.
>>>>>>
>>>>>>Filip
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: jean-philippe.belanger@(protected)
>>>>>>[mailto:jean-philippe.belanger@(protected)]
>>>>>>Sent: Thursday, January 08, 2004 11:46 AM
>>>>>>To: Tomcat Users List
>>>>>>Subject: Re: tomcat 5.0.16 Replication
>>>>>>
>>>>>>
>>>>>>The only changes in the ReplicationListener class is the try catch that
>>>>>>was added.
>>>>>>
>>>>>>the code logic is the same. Weird enough. So it's probably elsewhere
>>>>>>that something changed in the state of the SelectionKey.
>>>>>>
>>>>>>Jean-Philippe B�langer
>>>>>>
>>>>>>Steve Nelson wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>I was just about to try this actually. I found through
>>>>>>>
>>>>>>>
>googling alot of
>
>
>>>>>>>people
>>>>>>>having problems with select with 1.4 and NIO with Redhat 9. They were
>>>>>>>actually
>>>>>>>experiencing crashes though.
>>>>>>>
>>>>>>>To verify your results I just put a Thread.Sleep(1); where you
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>suggested and
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>I also see the jump in performance.
>>>>>>>
>>>>>>>Something must have changed in ReplicationListener that causes this
>>>>>>>because
>>>>>>>the 5.0.16
>>>>>>>version doesn't seem to have the problem. I'll see if I can figure
>>>>>>>it out
>>>>>>>when I get back to where I can diff the files.
>>>>>>>
>>>>>>>-Steve
>>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: jean-philippe.belanger@(protected)
>>>>>>>[mailto:jean-philippe.belanger@(protected)]
>>>>>>>Sent: Thursday, January 08, 2004 12:25 PM
>>>>>>>To: Tomcat Users List
>>>>>>>Subject: Re: tomcat 5.0.16 Replication
>>>>>>>
>>>>>>>
>>>>>>>More content for you Filip.
>>>>>>>
>>>>>>>I've checked and followed the code of the listen event in
>>>>>>>ReplicationListener.java
>>>>>>>
>>>>>>>Here's what happening:
>>>>>>>
>>>>>>>selector.select(timeout) -> return immediatly with one SelectorKey
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>available
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>That key is not Acceptable and not Readable so it immediatly
>>>>>>>
>>>>>>>
>skip those
>
>
>>>>>>>IFs and loops back to the beginning.
>>>>>>>
>>>>>>>I've put traces and this is executed once every millisecond hence the
>>>>>>>100% load on the server.
>>>>>>>Just to make sure, I've put a Thread.sleep(10) at the end of the loop
>>>>>>>and the CPU dropped back to 0% and the replication still worked nicely
>>>>>>>but probably a little slower since the wait of 10ms.
>>>>>>>
>>>>>>>I don't know much about those NIO packages but seams like the
>>>>>>>select(timeout) method shouldn't return a SelectorKey of that state.
>>>>>>>with any waiting.
>>>>>>>
>>>>>>>Let me know what you can dig from those.
>>>>>>>
>>>>>>>Jean-Philippe B�langer
>>>>>>>
>>>>>>>jean-philippe.belanger@(protected):
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Hi Filip.
>>>>>>>>
>>>>>>>>I did some profiling of 40mins of tomcat with and without a 2nd node
>>>>>>>>up. here are the results with
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>-Xrunhprof:cpu=samples,thread=y,file=/u01/portal/java.hprof.txt,depth=10:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>>>>Those number are cpu=times and not samples since the later
>>>>>>>>
>>>>>>>>
>one freezes
>
>
>>>>>>>>on my systems.
>>>>>>>>So that list shows the time spent in each methods.
>>>>>>>>
>>>>>>>>Major difference the some call to the
sun.nio.ch.PollArrayWrapper>>>>>>>>class. I don't know much about those NIOs packages but 819000 call in
>>>>>>>>40 mins is a lot.
>>>>>>>>The Socket Interface was called more than twice with 2 hosts
>>>>>>>>
>>>>>>>>
>than with
>
>
>>>>>>>>a single one. Which seams normal.
>>>>>>>>
>>>>>>>>Maybe this can help.
>>>>>>>>If you need the complete hprof file I can send them to you.
>>>>>>>>
>>>>>>>>1 host in cluster:
>>>>>>>>CPU TIME (ms) BEGIN (total = 19701) Thu Jan 8 10:00:59 2004
>>>>>>>>rank self accum count trace method
>>>>>>>>1 11.48% 11.48% 54 85
java.lang.Object.wait>>>>>>>>2 11.46% 22.94% 117 86
java.lang.Object.wait>>>>>>>>3 10.95% 33.89% 4115 215
>>>>>>>>
>>>>>>>>
>
java.net.PlainDatagramSocketImpl.receive>
>
>>>>>>>>4 10.93% 44.81% 4114 224
java.lang.Thread.sleep>>>>>>>>5 10.91% 55.73% 19005 214
sun.nio.ch.PollArrayWrapper.poll0>>>>>>>>6 7.37% 63.09% 28 495
java.lang.Object.wait>>>>>>>>7 7.24% 70.34% 10 576
java.lang.Object.wait>>>>>>>>8 4.57% 74.90% 90 716
java.lang.Thread.sleep>>>>>>>>9 4.48% 79.38% 1 909
java.lang.Object.wait>>>>>>>>10 4.48% 83.86% 1 908
java.lang.Object.wait>>>>>>>>11 4.48% 88.34% 15 810
java.lang.Object.wait>>>>>>>>12 4.47% 92.81% 1 910
java.net.PlainSocketImpl.socketAccept>>>>>>>>13 0.71% 93.52% 2 623
java.lang.Object.wait>>>>>>>>14 0.56% 94.08% 2 706
java.lang.Object.wait>>>>>>>>15 0.38% 94.46% 2 914
java.lang.Object.wait>>>>>>>>16 0.24% 94.70% 775 913
java.lang.String.toCharArray>>>>>>>>17 0.23% 94.93% 3 475
java.lang.Thread.sleep>>>>>>>>18 0.16% 95.09% 2 472
java.lang.Object.wait>>>>>>>>19 0.15% 95.24% 2 595
java.lang.Thread.sleep>>>>>>>>20 0.15% 95.40% 2 586
java.lang.Thread.sleep>>>>>>>>21 0.15% 95.55% 2 703
java.lang.Thread.sleep>>>>>>>>22 0.15% 95.70% 2 476
java.lang.Thread.sleep>>>>>>>>23 0.15% 95.85% 2 692
java.lang.Thread.sleep>>>>>>>>24 0.12% 95.97% 218595 385
>>>>>>>>java.lang.CharacterDataLatin1.toLowerCase
>>>>>>>>25 0.12% 96.09% 218595 408
java.lang.Character.toLowerCase>>>>>>>>26 0.11% 96.20% 218595 433
>>>>>>>>java.lang.CharacterDataLatin1.getProperties
>>>>>>>>27 0.10% 96.30% 210925 389
java.lang.String.equalsIgnoreCase>>>>>>>>28 0.08% 96.38% 157259 387
java.lang.String.charAt>>>>>>>>29 0.08% 96.46% 1 646
java.lang.Thread.sleep>>>>>>>>30 0.08% 96.53% 1 634
java.lang.Thread.sleep>>>>>>>>31 0.08% 96.61% 1 903
java.lang.Thread.sleep>>>>>>>>32 0.08% 96.69% 1 714
java.lang.Thread.sleep>>>>>>>>33 0.08% 96.76% 1 811
java.lang.Thread.sleep>>>>>>>>34 0.08% 96.84% 1 715
java.lang.Thread.sleep>>>>>>>>
>>>>>>>>2 hosts:
>>>>>>>>CPU TIME (ms) BEGIN (total = 37247) Thu Jan 8 11:01:28 2004
>>>>>>>>rank self accum count trace method
>>>>>>>>1 9.56% 9.56% 52 85
java.lang.Object.wait>>>>>>>>2 9.56% 19.12% 29 86
java.lang.Object.wait>>>>>>>>3 9.30% 28.43% 3 267
java.lang.Object.wait>>>>>>>>4 9.25% 37.68% 6644 224
java.lang.Thread.sleep>>>>>>>>5 9.23% 46.91% 13116 215
>>>>>>>>
>>>>>>>>
>
java.net.PlainDatagramSocketImpl.receive>
>
>>>>>>>>6 7.67% 54.58% 3 266
java.lang.Object.wait>>>>>>>>7 5.90% 60.47% 39 847
java.lang.Object.wait>>>>>>>>8 5.76% 66.24% 12 503
java.lang.Object.wait>>>>>>>>9 3.90% 70.14% 145 975
java.lang.Thread.sleep>>>>>>>>10 3.90% 74.04% 1 1174
java.lang.Object.wait>>>>>>>>11 3.90% 77.94% 1 1173
java.lang.Object.wait>>>>>>>>12 3.90% 81.84% 25 973
java.lang.Object.wait>>>>>>>>13 3.90% 85.74% 1 1175
java.net.PlainSocketImpl.socketAccept>>>>>>>>14 3.88% 89.62% 819692 214
sun.nio.ch.PollArrayWrapper.poll0>>>>>>>>15 0.75% 90.37% 2 958
java.lang.Object.wait>>>>>>>>16 0.28% 90.65% 2 457
java.lang.Object.wait>>>>>>>>17 0.26% 90.91% 2 1181
java.lang.Object.wait>>>>>>>>
>>>>>>>>Filip Hanik wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>I'll try to get an instance going today. Will let you know how it
>>>>>>>>>goes
>>>>>>>>>also, try asynchronous replication, does it still go to 100%?
>>>>>>>>>
>>>>>>>>>Filip
>>>>>>>>>
>>>>>>>>>-----Original Message-----
>>>>>>>>>From: Steve Nelson [mailto:Steve.Nelson@(protected)]
>>>>>>>>>Sent: Wednesday, January 07, 2004 12:08 PM
>>>>>>>>>To: 'Tomcat Users List'
>>>>>>>>>Subject: RE: tomcat 5.0.16 Replication
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>Okay, did that got this
>>>>>>>>>
>>>>>>>>>BEGIN TO RECEIVE
>>>>>>>>>SENT:Default 1
>>>>>>>>>RECEIVED:Default 1 FROM /10.0.0.110:5555
>>>>>>>>>SENT:Default 2
>>>>>>>>>BEGIN TO RECEIVE
>>>>>>>>>RECEIVED:Default 2 FROM /10.0.0.110:5555
>>>>>>>>>SENT:Default 3
>>>>>>>>>BEGIN TO RECEIVE
>>>>>>>>>RECEIVED:Default 3 FROM /10.0.0.110:5555
>>>>>>>>>SENT:Default 4
>>>>>>>>>BEGIN TO RECEIVE
>>>>>>>>>RECEIVED:Default 4 FROM /10.0.0.110:5555
>>>>>>>>>
>>>>>>>>>*shrug*
>>>>>>>>>
>>>>>>>>>BTW It didn't go to 100% CPU ute before I started using the
>>>>>>>>>
>>>>>>>>>
>code from
>
>
>>>>>>>>>CVS.
>>>>>>>>>Of course the Manager would almost always timeout before it would
>>>>>>>>>recieve
>>>>>>>>>the message.
>>>>>>>>>
>>>>>>>>>Now it gets the message right away, but maxes my machine out.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>-----Original Message-----
>>>>>>>>>From: Filip Hanik [mailto:devlists@(protected)]
>>>>>>>>>Sent: Wednesday, January 07, 2004 1:58 PM
>>>>>>>>>To: Tomcat Users List
>>>>>>>>>Subject: RE: tomcat 5.0.16 Replication
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>100% cpu can mean that you have a multicast problem, try to run
>>>>>>>>>
>>>>>>>>>java -cp tomcat-replication.jar MCaster
>>>>>>>>>
>>>>>>>>>download the jar from http://cvs.apache.org/~fhanik/
>>>>>>>>>
>>>>>>>>>Filip
>>>>>>>>>
>>>>>>>>>-----Original Message-----
>>>>>>>>>From: Steve Nelson [mailto:Steve.Nelson@(protected)]
>>>>>>>>>Sent: Wednesday, January 07, 2004 6:51 AM
>>>>>>>>>To: 'tomcat-user@(protected)'
>>>>>>>>>Subject: tomcat 5.0.16 Replication
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>I was having random problems with clustering when starting
>>>>>>>>>
>>>>>>>>>
>up. Mostly
>
>
>>>>>>>>>it had
>>>>>>>>>to do with Timing out
>>>>>>>>>when the manager was starting up. I built the CVS version and it
>>>>>>>>>solved that
>>>>>>>>>problem. But it has caused
>>>>>>>>>some serious performance problems.
>>>>>>>>>
>>>>>>>>>First a little background.
>>>>>>>>>
>>>>>>>>>I have 2 servers, dual 300mhz cpq proliants, both running
>>>>>>>>>
>>>>>>>>>
>Redhat - 9,
>
>
>>>>>>>>>Tomcat
>>>>>>>>>5.0.16 (with catalina-cluster.jar build from cvs) The multicast
>>>>>>>>>packets are
>>>>>>>>>restricted to a crossover link between the servers. There
>>>>>>>>>
>>>>>>>>>
>are 3 hosts
>
>
>>>>>>>>>in the
>>>>>>>>>server.xml, all with clustering set up. They all function just fine.
>>>>>>>>>
>>>>>>>>>But.....the cpu's spikes up to 100% if I start up both servers. I
>>>>>>>>>know this
>>>>>>>>>didn't happen without the new catalina-cluster.jar. If I shut down 1
>>>>>>>>>server
>>>>>>>>>(doesn't matter which) everything returns to normal. But when both
>>>>>>>>>are
>>>>>>>>>running both servers are at 100% CPU. I am trying to profile it now,
>>>>>>>>>but I
>>>>>>>>>figured if someone has already experienced this they could save me
>>>>>>>>>some
>>>>>>>>>time.
>>>>>>>>>
>>>>>>>>>Oh, and there isn't anything relevant in my logs. It's not throwing
>>>>>>>>>millions
>>>>>>>>>of errors or something.
>>>>>>>>>
>>>>>>>>>-Steve Nelson
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>------------------------------------------------------------
>>>>>>>>>
>>>>>>>>>
>---------
>
>
>>>>>>>>>To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
>>>>>>>>>For additional commands, e-mail: tomcat-user-help@(protected)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>------------------------------------------------------------
>>>>>>>>>
>>>>>>>>>
>---------
>
>
>>>>>>>>>To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
>>>>>>>>>For additional commands, e-mail: tomcat-user-help@(protected)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>---------------------------------------------------------------------
>>>>>>>>To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
>>>>>>>>For additional commands, e-mail: tomcat-user-help@(protected)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>--
>>>>>>Jean-Philippe B�langer
>>>>>>(514)228-8800 ext 3060
>>>>>>111 Duke
>>>>>>CGI
>>>>>>
>>>>>>
>>>>>>---------------------------------------------------------------------
>>>>>>To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
>>>>>>For additional commands, e-mail: tomcat-user-help@(protected)
>>>>>>
>>>>>>
>>>>>>---------------------------------------------------------------------
>>>>>>To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
>>>>>>For additional commands, e-mail: tomcat-user-help@(protected)
>>>>>>
>>>>>>
>>>>>>---------------------------------------------------------------------
>>>>>>To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
>>>>>>For additional commands, e-mail: tomcat-user-help@(protected)
>>>>>>
>>>>>>
>>>>>>---------------------------------------------------------------------
>>>>>>To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
>>>>>>For additional commands, e-mail: tomcat-user-help@(protected)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>--
>>>Jean-Philippe B�langer
>>>(514)228-8800 ext 3060
>>>111 Duke
>>>CGI
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
>>>For additional commands, e-mail: tomcat-user-help@(protected)
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
>>>For additional commands, e-mail: tomcat-user-help@(protected)
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
>>>For additional commands, e-mail: tomcat-user-help@(protected)
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
>>>For additional commands, e-mail: tomcat-user-help@(protected)
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
>>For additional commands, e-mail: tomcat-user-help@(protected)
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
>>For additional commands, e-mail: tomcat-user-help@(protected)
>>
>>
>>
>>
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
>For additional commands, e-mail: tomcat-user-help@(protected)
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
>For additional commands, e-mail: tomcat-user-help@(protected)
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
For additional commands, e-mail: tomcat-user-help@(protected)
