Re: [Fwd: Re: DGC threads issue]

2012-01-13 Thread Peter Firmstone
Ok, found the problem, when I fixed River-142, I introduced a new bug, after creating a new DGC thread, I didn't set the running flag to true, so each time, a new thread is created. Thankfully it's a very easy fix. Cheers, Peter. Peter Jones wrote: Peter, That internal Executor interface

Re: Problem starting the reggie service

2012-01-13 Thread Dan Creswell
Hello, My mind is aged so I may or may not be remembering correctly but I think that means of starting reggie only work in Jini 1.x. As of Jini 2.x and the following River project we use the service starter in start.jar for the purpose of booting services. Two things then: (1) Could you please

Re: DGC threads issue

2012-01-13 Thread Peter Jones
Bryan, I meant that it might help for the list to see the specific threads in question, as they appear in a JVM thread dump (name, stack frames, etc.), just to be sure that we're talking about the same thing. There is more than one kind of thread related to DGC, and it seems that the

Re: DGC threads issue

2012-01-13 Thread Peter Jones
Which is why the Object.equals/hashCode for an endpoint implementation is critical. -- Peter On Jan 13, 2012, at 2:05 AM, Gregg Wonderly wrote: I would say, that it's very easy to just code up a configuration entry, or a dynamic construction in code where a new endpoint is also created per

RE: DGC threads issue

2012-01-13 Thread Bryan Thompson
Peter, Can you clarify what you mean by the end point in this context? That would be the server side object which is being exported? I.e., the proxy wrapping the Future? Or would this be the long lived service which is exported and against which the requests are being made? If you are

Re: DGC threads issue

2012-01-13 Thread Peter Jones
Bryan, In your example below, I'm referring to TcpServerEndpoint and its associated classes (it's its ListenEndpoint and Endpoint implementations for which Object.equals/hashCode are critical), because that's what you're using in your exporters. And the standard TcpServerEndpoint should be

Re: Removing the need for config files

2012-01-13 Thread Gregg Wonderly
I think the Configuration interface has a lot of simplicity going for it. I also think that there could be some additional value provided in some changes to that interface. But, I'd suggest doing anything like that in a sub-interface. public interface OtherBitsForConfiguration extends

Re: DGC threads issue

2012-01-13 Thread Peter Jones
Bryan, Thanks, that is indeed helpful to see, to be clear about which kind of threads are causing the problem. -- Peter On Jan 13, 2012, at 9:52 AM, Bryan Thompson wrote: Peter, There is very little information in there. Basically a whole lot of DGC Lease Checker threads all sleeping

Re: DGC threads issue

2012-01-13 Thread Simon IJskes - QCG
On 13-01-12 16:08, Peter Jones wrote: Bryan, In your example below, I'm referring to TcpServerEndpoint and its associated classes (it's its ListenEndpoint and Endpoint implementations for which Object.equals/hashCode are critical), because that's what you're using in your exporters. And the

RE: [Fwd: Re: DGC threads issue]

2012-01-13 Thread Bryan Thompson
What about the following property? Is it still valid? -Dsun.rmi.transport.tcp.connectionPool=true Thanks, Bryan -Original Message- From: Peter Firmstone [mailto:j...@zeus.net.au] Sent: Friday, January 13, 2012 8:41 AM To: Bryan Thompson Cc: dev@river.apache.org;

Re: [Fwd: Re: DGC threads issue]

2012-01-13 Thread Peter Firmstone
Only if you use JrmpExporter. I'll get back to shortly with some build instructions. Cheers, Peter. Bryan Thompson wrote: What about the following property? Is it still valid? -Dsun.rmi.transport.tcp.connectionPool=true Thanks, Bryan -Original Message- From: Peter