Re: Reggie
Per Edlund <[email protected]> Fri, 26 Jun 2009 10:29:26 +0200
| Newsgroups | gmane.comp.java.sun.jini |
|---|---|
| Message-ID | <[email protected]> |
--00163646db766b1c56046d3c2384 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi! Thanks for the replys! As it seams, this issue is related to client machines. If a client machine get's memoty issues, and reggie is trying to notify the client (which uses a servicechache listening on all service events), reggie chokes when the client can't reply to reggie. Fixiing the memory issues on the client get's rid of the behaviour on reggie Just thouth I should tell Cheers /Per On Wed, May 27, 2009 at 3:47 PM, Juan Ramirez <[email protected]> wrote: > Hi, Peter. Reggie does queue up discovery requests and event notifications > and services these with threads from the same pool. It is possible that > there is a large number of event notifications to be delivered to the > LookupCache instances thus delaying the processing of discovery requests. > You could set Reggie's logging level to FINEST to see what Reggie is doing > at the time it appears to "choke". There is additional info on this > scenario in the following CRs. > > https://issues.apache.org/jira/browse/RIVER-52 > https://issues.apache.org/jira/browse/RIVER-197 > > Hope this helps, > > Juan > > > On 05/27/09 07:17, Per Edlund wrote: > >> Hi! >> >> We'ev been using Jini for quite som time now but havn't upgraded after the >> 2.1 release. We're currently experiencing some issues with reggie choking >> the machine and we can't really tell why. The number of jiniservices we have >> is around 60 (these are client's as well, and on top of this we have >> webservers which are clients (around 100-200)) , we use the LookupCache etc, >> but efery now and then we have to restart the VM running reggie. Doing a >> discovery during this time get's no lookup, and services can't be found. >> >> If we look at how services register/unregister, that seam to take an >> aweful long time when reggie is starting to choke, and out theory is that >> reggie uses some kind of queue which grows more than it can be processed. >> >> Does any one have an idea on how to dig into this? >> >> Env: Linux Debian, Sun Java 1.5&1.6 >> >> Kind regards >> /Per >> -------------------------------------------------------------------------- >> Getting Started: http://www.jini.org/wiki/Category:Getting_StartedCommunity Web Site: >> http://jini.org jini-users Archive: >> http://archives.java.sun.com/archives/jini-users.html Unsubscribing: >> email "signoff JINI-USERS" to [email protected] >> > > -- ******************************************** Per Edlund www.bozoka.com [email protected] +46(0)8 545 068 05 +46(0)703 71 70 02 ******************************************** -------------------------------------------------------------------------- Getting Started: http://www.jini.org/wiki/Category:Getting_Started Community Web Site: http://jini.org jini-users Archive: http://archives.java.sun.com/archives/jini-users.html Unsubscribing: email "signoff JINI-USERS" to [email protected] --00163646db766b1c56046d3c2384 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi!<br><br>Thanks for the replys!<br><br>As it seams, this issue is related= to client machines. If a client machine get's memoty issues, and reggi= e is trying to notify the client (which uses a servicechache listening on a= ll service events), reggie chokes when the client can't reply to reggie= .<br> <br>Fixiing the memory issues on the client get's rid of the behaviour = on reggie<br><br>Just thouth I should tell<br><br>Cheers<br>/Per<br><br><di= v class=3D"gmail_quote">On Wed, May 27, 2009 at 3:47 PM, Juan Ramirez <span= dir=3D"ltr"><<a href=3D"mailto:[email protected]">[email protected]= om</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi, Peter. =A0Reg= gie does queue up discovery requests and event notifications and services t= hese with threads from the same pool. =A0It is possible that there is a lar= ge number of event notifications to be delivered to the LookupCache instanc= es thus delaying the processing of discovery requests. =A0You could set Reg= gie's logging level to FINEST to see what Reggie is doing at the time i= t appears to "choke". =A0There is additional info on this scenari= o in the following CRs.<br> <br> <a href=3D"https://issues.apache.org/jira/browse/RIVER-52" target=3D"_blank= ">https://issues.apache.org/jira/browse/RIVER-52</a><br> <a href=3D"https://issues.apache.org/jira/browse/RIVER-197" target=3D"_blan= k">https://issues.apache.org/jira/browse/RIVER-197</a><br> <br> Hope this helps,<br> <br> Juan<div><div></div><div class=3D"h5"><br> <br> On 05/27/09 07:17, Per Edlund wrote:<br> </div></div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px sol= id rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>= <div></div><div class=3D"h5"> Hi!<br> <br> We'ev been using Jini for quite som time now but havn't upgraded af= ter the 2.1 release. We're currently experiencing some issues with regg= ie choking the machine and we can't really tell why. The number of jini= services we have is around 60 (these are client's as well, and on top o= f this we have webservers which are clients (around 100-200)) , we use the = LookupCache etc, but efery now and then we have to restart the VM running r= eggie. Doing a discovery during this time get's no lookup, and services= can't be found.<br> <br> If we look at how services register/unregister, that seam to take an aweful= long time when reggie is starting to choke, and out theory is that reggie = uses some kind of queue which grows more than it can be processed.<br> <br> Does any one have an idea on how to dig into this?<br> <br> Env: Linux Debian, Sun Java 1.5&1.6<br> <br> Kind regards<br> /Per<br></div></div> -------------------------------------------------------------------------- = Getting Started: <a href=3D"http://www.jini.org/wiki/Category:Getting_Start= ed" target=3D"_blank">http://www.jini.org/wiki/Category:Getting_Started</a>= Community Web Site: <a href=3D"http://jini.org" target=3D"_blank">http://j= ini.org</a> jini-users Archive: <a href=3D"http://archives.java.sun.com/arc= hives/jini-users.html" target=3D"_blank">http://archives.java.sun.com/archi= ves/jini-users.html</a> Unsubscribing: email "signoff JINI-USERS"= to <a href=3D"mailto:[email protected]" target=3D"_blank">listserv@jav= a.sun.com</a><br> </blockquote> <br> </blockquote></div><br><br clear=3D"all"><br>-- <br>***********************= *********************<br>Per Edlund<br><a href=3D"http://www.bozoka.com">ww= w.bozoka.com</a><br><a href=3D"mailto:[email protected]">[email protected]</a><br= > +46(0)8 545 068 05<br>+46(0)703 71 70 02<br>*******************************= *************<br> -------------------------------------------------------------------------- Getting Started: http://www.jini.org/wiki/Category:Getting_Started Community Web Site: http://jini.org jini-users Archive: http://archives.java.sun.com/archives/jini-users.html Unsubscribing: email "signoff JINI-USERS" to [email protected] --00163646db766b1c56046d3c2384--