You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@river.apache.org by Ashutosh Singh <dh...@hotmail.com> on 2011/12/15 12:36:31 UTC
what should be written in a config file for service application?
Hi,
I am a novice RIVER user?
Can you please tell me what should be written in a config file for a service application?
Regards
Ashutosh Singh
Re: what should be written in a config file for service
application?
Posted by Greg Trasuk <tr...@stratuscom.com>.
On Thu, 2011-12-15 at 06:36, Ashutosh Singh wrote:
> Hi,
>
> I am a novice RIVER user?
>
> Can you please tell me what should be written in a config file for a service application?
>
> Regards
> Ashutosh Singh
>
There's a basic configuration file for non-secure services at:
http://svn.apache.org/viewvc/river/extra/RiverConfigurationResources/trunk/src/nonSecureClient.config?view=markup
Cheers,
Greg.
Re: DGC threads issue
Posted by Simon IJskes - QCG <si...@qcg.nl>.
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 standard
> TcpServerEndpoint should be fine in this regard.
>
> -- Peter
And: http://river.apache.org/user-guide-socketfactories.html
(i've mailed it to river-user as well, but i did'nt see it there)
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: DGC threads issue
Posted by Peter Jones <pc...@roundroom.net>.
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 fine in this regard.
-- Peter
On Jan 13, 2012, at 9:44 AM, Bryan Thompson wrote:
> 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 talking about the RemoteFutureImpl class (in the code below), then it does not override equals()/hashCode(). However, I am unsure how anything would benefit from that it if did as no two futures (or their server side wrappers) should be equals().
>
> The code to export the Future from the long lived service looks like this:
>
> public <E> Future<E> getProxy(final Future<E> future) {
>
> /*
> * Setup the Exporter for the Future.
> *
> * Note: Distributed garbage collection is enabled since the proxied
> * future CAN become locally weakly reachable sooner than the client can
> * get() the result. Distributed garbage collection handles this for us
> * and automatically unexports the proxied iterator once it is no longer
> * strongly referenced by the client.
> */
> final Exporter exporter = getExporter(true/* enableDGC */);
>
> // wrap the future in a proxyable object.
> final RemoteFuture<E> impl = new RemoteFutureImpl<E>(future);
>
> /*
> * Export the proxy.
> */
> final RemoteFuture<E> proxy;
> try {
>
> // export proxy.
> proxy = (RemoteFuture<E>) exporter.export(impl);
>
> if (log.isInfoEnabled()) {
>
> log.info("Exported proxy: proxy=" + proxy + "("
> + proxy.getClass() + ")");
>
> }
>
> } catch (ExportException ex) {
>
> throw new RuntimeException("Export error: " + ex, ex);
>
> }
>
> // return proxy to caller.
> return new ClientFuture<E>(proxy);
>
> }
>
> /**
> * Return an {@link Exporter} for a single object that implements one or
> * more {@link Remote} interfaces.
> * <p>
> * Note: This uses TCP Server sockets.
> * <p>
> * Note: This uses [port := 0], which means a random port is assigned.
> * <p>
> * Note: The VM WILL NOT be kept alive by the exported proxy (keepAlive is
> * <code>false</code>).
> *
> * @param enableDGC
> * if distributed garbage collection should be used for the
> * object to be exported.
> *
> * @return The {@link Exporter}.
> */
> protected Exporter getExporter(final boolean enableDGC) {
>
> return new BasicJeriExporter(TcpServerEndpoint
> .getInstance(0/* port */), invocationLayerFactory, enableDGC,
> false/* keepAlive */);
>
> }
>
> The code to export the long lived service looks like this:
>
> /*
> * Extract how the service will provision itself from the
> * Configuration.
> */
>
> // The exporter used to expose the service proxy.
> exporter = (Exporter) config.getEntry(//
> getClass().getName(), // component
> ConfigurationOptions.EXPORTER, // name
> Exporter.class, // type (of the return object)
> /*
> * The default exporter is a BasicJeriExporter using a
> * TcpServerEnpoint.
> */
> new BasicJeriExporter(TcpServerEndpoint.getInstance(0),
> new BasicILFactory())
> );
>
> /*
> * Export a proxy object for this service instance.
> *
> * Note: This must be done before we start the join manager since the
> * join manager will register the proxy.
> */
> try {
>
> proxy = exporter.export(impl);
>
> if (log.isInfoEnabled())
> log.info("Proxy is " + proxy + "(" + proxy.getClass() + ")");
>
> } catch (ExportException ex) {
>
> fatal("Export error: "+this, ex);
>
> }
>
> Thanks,
> Bryan
>
>> -----Original Message-----
>> From: Peter Jones [mailto:pcj@roundroom.net]
>> Sent: Friday, January 13, 2012 9:33 AM
>> To: dev@river.apache.org
>> Subject: Re: DGC threads issue
>>
>> 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 each Exporter. That can
>> quickly turn into a problematic situation in cases like this,
>> where there are lots of "quick" exports followed by
>> termination without "unexport" being done directly as part of
>> the returning context.
>>>
>>> Gregg Wonderly
>>>
>>> On Jan 13, 2012, at 12:01 AM, Peter Firmstone wrote:
>>>
>>>> Is there another way to create an Endpoint per exported
>> object? I'm just thinking, it seems unlikely that Brian's
>> implemented his own Endpoint, but are there any other error
>> conditions or incorrect use scenarios that could produce the
>> same problem?
>>>>
>>>> Cheers,
>>>>
>>>> Peter.
>>>>
>>>> Peter Jones wrote:
>>>>> Bryan,
>>>>>
>>>>> DGC threads should not be per exported object. Generally
>> speaking, they tend to be per endpoint (at which there are
>> one or more remote objects exported). Are you using any sort
>> of custom endpoint implementation? Problems like this can
>> occur when an endpoint implementation doesn't implement
>> Object.equals and hashCode appropriately, so the expected
>> batching of threads (and communication) per endpoint does not occur.
>>>>>
>>>>> It might help to see, from a thread dump, exactly which
>> DGC threads are causing this problem. And they are in the
>> server JVM (with all the exported remote objects), not the
>> remote callers' JVM(s)?
>>>>>
>>>>> -- Peter
>>>>>
>>>>>
>>>>> On Jan 12, 2012, at 3:45 PM, Tom Hobbs wrote:
>>>>>
>>>>>
>>>>>> Hi Bryan,
>>>>>>
>>>>>> Sorry that no one got back to you about this. I'm afraid that I
>>>>>> don't know the answer to your question, I've copied the dev list
>>>>>> into this email in case someone who monitors that list (but not
>>>>>> this one) has any ideas.
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Tom
>>>>>>
>>>>>> On Thu, Jan 12, 2012 at 2:29 PM, Bryan Thompson
>> <br...@systap.com> wrote:
>>>>>>
>>>>>>> Just to follow up on this thread myself. I modified
>> the pattern to return a "thick" future rather than a proxy
>> for the future. This caused the RMI call to wait on the
>> server until the future was done and then sent back the
>> outcome. This "fixed" the DGC memory/thread leak by reducing
>> the number of exported proxies drammatically.
>>>>>>>
>>>>>>> In terms of best practices, is distributed DGC simply
>> not useful for exported objects with short life spans? Can
>> it only be used with proxies for relatively long lived services?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Bryan
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Bryan Thompson
>>>>>>>> Sent: Tuesday, January 03, 2012 12:06 PM
>>>>>>>> To: user@river.apache.org
>>>>>>>> Subject: DGC threads issue
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Background:
>>>>>>>>
>>>>>>>> I am seeing what would appear to be one DGC thread
>> allocated per
>>>>>>>> exported object. This is using River 2.2 and Sun JDK
>> 1.6.0_17.
>>>>>>>> Relevant configuration parameters are below.
>>>>>>>>
>>>>>>>> I am observing problems with the DGC threads not being
>> retired on
>>>>>>>> a timely basis. The exported objects are proxies for Futures
>>>>>>>> which are being executed on the service. The code pattern is
>>>>>>>> such that the proxied Future goes out of lexical scope quite
>>>>>>>> quickly. E.g., rmiCallReturningProxyForFuture().get().
>>>>>>>>
>>>>>>>> Under a modest load, a large number of such Futures
>> are exported
>>>>>>>> which results in a large number of long lived DGC
>> threads. This
>>>>>>>> turns into a problem for the JVM due to the stack
>> allocation per
>>>>>>>> thread. Presumably this is not good for other reasons as well
>>>>>>>> (e.g., scheduling).
>>>>>>>>
>>>>>>>> I have tried to override the leaseValue and checkInterval
>>>>>>>> defaults per the configuration options below. I
>> suspect that the
>>>>>>>> lease interval is somehow not being obeyed, which is
>> presumably a
>>>>>>>> problem on my end. However, I can verify that the
>> configuration
>>>>>>>> values are in fact showing up in
>>>>>>>> System.getProperties() for at least some of the JVMs involved
>>>>>>>> (the one which drives the workload and the one that I am
>>>>>>>> monitoring with the large number of DGC lease threads).
>>>>>>>>
>>>>>>>> Some questions:
>>>>>>>>
>>>>>>>> Is this one-thread-per-exported proxy the expected
>> behavior when
>>>>>>>> DGC is requested for the exported object?
>>>>>>>>
>>>>>>>> The DGC lease checker threads appear to expire ~14 -
>> 15 minutes
>>>>>>>> after I terminate the process which was originating the RMI
>>>>>>>> requests. This is close the sum of the default
>> leaseValue (10m)
>>>>>>>> and checkInterval (5m) parameters, but maybe there is
>> some other
>>>>>>>> timeout which is controlling this? If this is the sum
>> of those
>>>>>>>> parameters, why would the DGC lease threads live until
>> the sum of
>>>>>>>> those values? I thought that the lease would expire after the
>>>>>>>> leaseValue (10m default).
>>>>>>>>
>>>>>>>> Can the issue I am observing be caused by a low heap
>> pressure on
>>>>>>>> the JVM to which the RMI proxies were exported? If it
>> fails to
>>>>>>>> GC those proxies, even though they are reachable, could that
>>>>>>>> cause DGC to continue to retain those proxies on the JVM which
>>>>>>>> exported them?
>>>>>>>>
>>>>>>>> Is there any way to configure DGC to use a thread pool
>> or to have
>>>>>>>> the leases managed by a single thread?
>>>>>>>>
>>>>>>>> Is it possible that there is an interaction with the
>> useNIO option?
>>>>>>>>
>>>>>>>> Relevant options that I am using include:
>>>>>>>>
>>>>>>>> -Dcom.sun.jini.jeri.tcp.useNIO=true
>>>>>>>> -Djava.rmi.dgc.leaseValue=30000
>>>>>>>> -Dsun.rmi.dgc.checkInterval=15000
>>>>>>>> -Dsun.rmi.transport.tcp.connectionPool=true
>>>>>>>>
>>>>>>>> Thanks in advance,
>>>>>>>> Bryan
>>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
RE: DGC threads issue
Posted by Bryan Thompson <br...@systap.com>.
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 talking about the RemoteFutureImpl class (in the code below), then it does not override equals()/hashCode(). However, I am unsure how anything would benefit from that it if did as no two futures (or their server side wrappers) should be equals().
The code to export the Future from the long lived service looks like this:
public <E> Future<E> getProxy(final Future<E> future) {
/*
* Setup the Exporter for the Future.
*
* Note: Distributed garbage collection is enabled since the proxied
* future CAN become locally weakly reachable sooner than the client can
* get() the result. Distributed garbage collection handles this for us
* and automatically unexports the proxied iterator once it is no longer
* strongly referenced by the client.
*/
final Exporter exporter = getExporter(true/* enableDGC */);
// wrap the future in a proxyable object.
final RemoteFuture<E> impl = new RemoteFutureImpl<E>(future);
/*
* Export the proxy.
*/
final RemoteFuture<E> proxy;
try {
// export proxy.
proxy = (RemoteFuture<E>) exporter.export(impl);
if (log.isInfoEnabled()) {
log.info("Exported proxy: proxy=" + proxy + "("
+ proxy.getClass() + ")");
}
} catch (ExportException ex) {
throw new RuntimeException("Export error: " + ex, ex);
}
// return proxy to caller.
return new ClientFuture<E>(proxy);
}
/**
* Return an {@link Exporter} for a single object that implements one or
* more {@link Remote} interfaces.
* <p>
* Note: This uses TCP Server sockets.
* <p>
* Note: This uses [port := 0], which means a random port is assigned.
* <p>
* Note: The VM WILL NOT be kept alive by the exported proxy (keepAlive is
* <code>false</code>).
*
* @param enableDGC
* if distributed garbage collection should be used for the
* object to be exported.
*
* @return The {@link Exporter}.
*/
protected Exporter getExporter(final boolean enableDGC) {
return new BasicJeriExporter(TcpServerEndpoint
.getInstance(0/* port */), invocationLayerFactory, enableDGC,
false/* keepAlive */);
}
The code to export the long lived service looks like this:
/*
* Extract how the service will provision itself from the
* Configuration.
*/
// The exporter used to expose the service proxy.
exporter = (Exporter) config.getEntry(//
getClass().getName(), // component
ConfigurationOptions.EXPORTER, // name
Exporter.class, // type (of the return object)
/*
* The default exporter is a BasicJeriExporter using a
* TcpServerEnpoint.
*/
new BasicJeriExporter(TcpServerEndpoint.getInstance(0),
new BasicILFactory())
);
/*
* Export a proxy object for this service instance.
*
* Note: This must be done before we start the join manager since the
* join manager will register the proxy.
*/
try {
proxy = exporter.export(impl);
if (log.isInfoEnabled())
log.info("Proxy is " + proxy + "(" + proxy.getClass() + ")");
} catch (ExportException ex) {
fatal("Export error: "+this, ex);
}
Thanks,
Bryan
> -----Original Message-----
> From: Peter Jones [mailto:pcj@roundroom.net]
> Sent: Friday, January 13, 2012 9:33 AM
> To: dev@river.apache.org
> Subject: Re: DGC threads issue
>
> 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 each Exporter. That can
> quickly turn into a problematic situation in cases like this,
> where there are lots of "quick" exports followed by
> termination without "unexport" being done directly as part of
> the returning context.
> >
> > Gregg Wonderly
> >
> > On Jan 13, 2012, at 12:01 AM, Peter Firmstone wrote:
> >
> >> Is there another way to create an Endpoint per exported
> object? I'm just thinking, it seems unlikely that Brian's
> implemented his own Endpoint, but are there any other error
> conditions or incorrect use scenarios that could produce the
> same problem?
> >>
> >> Cheers,
> >>
> >> Peter.
> >>
> >> Peter Jones wrote:
> >>> Bryan,
> >>>
> >>> DGC threads should not be per exported object. Generally
> speaking, they tend to be per endpoint (at which there are
> one or more remote objects exported). Are you using any sort
> of custom endpoint implementation? Problems like this can
> occur when an endpoint implementation doesn't implement
> Object.equals and hashCode appropriately, so the expected
> batching of threads (and communication) per endpoint does not occur.
> >>>
> >>> It might help to see, from a thread dump, exactly which
> DGC threads are causing this problem. And they are in the
> server JVM (with all the exported remote objects), not the
> remote callers' JVM(s)?
> >>>
> >>> -- Peter
> >>>
> >>>
> >>> On Jan 12, 2012, at 3:45 PM, Tom Hobbs wrote:
> >>>
> >>>
> >>>> Hi Bryan,
> >>>>
> >>>> Sorry that no one got back to you about this. I'm afraid that I
> >>>> don't know the answer to your question, I've copied the dev list
> >>>> into this email in case someone who monitors that list (but not
> >>>> this one) has any ideas.
> >>>>
> >>>> Best regards,
> >>>>
> >>>> Tom
> >>>>
> >>>> On Thu, Jan 12, 2012 at 2:29 PM, Bryan Thompson
> <br...@systap.com> wrote:
> >>>>
> >>>>> Just to follow up on this thread myself. I modified
> the pattern to return a "thick" future rather than a proxy
> for the future. This caused the RMI call to wait on the
> server until the future was done and then sent back the
> outcome. This "fixed" the DGC memory/thread leak by reducing
> the number of exported proxies drammatically.
> >>>>>
> >>>>> In terms of best practices, is distributed DGC simply
> not useful for exported objects with short life spans? Can
> it only be used with proxies for relatively long lived services?
> >>>>>
> >>>>> Thanks,
> >>>>> Bryan
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Bryan Thompson
> >>>>>> Sent: Tuesday, January 03, 2012 12:06 PM
> >>>>>> To: user@river.apache.org
> >>>>>> Subject: DGC threads issue
> >>>>>>
> >>>>>> Hello,
> >>>>>>
> >>>>>> Background:
> >>>>>>
> >>>>>> I am seeing what would appear to be one DGC thread
> allocated per
> >>>>>> exported object. This is using River 2.2 and Sun JDK
> 1.6.0_17.
> >>>>>> Relevant configuration parameters are below.
> >>>>>>
> >>>>>> I am observing problems with the DGC threads not being
> retired on
> >>>>>> a timely basis. The exported objects are proxies for Futures
> >>>>>> which are being executed on the service. The code pattern is
> >>>>>> such that the proxied Future goes out of lexical scope quite
> >>>>>> quickly. E.g., rmiCallReturningProxyForFuture().get().
> >>>>>>
> >>>>>> Under a modest load, a large number of such Futures
> are exported
> >>>>>> which results in a large number of long lived DGC
> threads. This
> >>>>>> turns into a problem for the JVM due to the stack
> allocation per
> >>>>>> thread. Presumably this is not good for other reasons as well
> >>>>>> (e.g., scheduling).
> >>>>>>
> >>>>>> I have tried to override the leaseValue and checkInterval
> >>>>>> defaults per the configuration options below. I
> suspect that the
> >>>>>> lease interval is somehow not being obeyed, which is
> presumably a
> >>>>>> problem on my end. However, I can verify that the
> configuration
> >>>>>> values are in fact showing up in
> >>>>>> System.getProperties() for at least some of the JVMs involved
> >>>>>> (the one which drives the workload and the one that I am
> >>>>>> monitoring with the large number of DGC lease threads).
> >>>>>>
> >>>>>> Some questions:
> >>>>>>
> >>>>>> Is this one-thread-per-exported proxy the expected
> behavior when
> >>>>>> DGC is requested for the exported object?
> >>>>>>
> >>>>>> The DGC lease checker threads appear to expire ~14 -
> 15 minutes
> >>>>>> after I terminate the process which was originating the RMI
> >>>>>> requests. This is close the sum of the default
> leaseValue (10m)
> >>>>>> and checkInterval (5m) parameters, but maybe there is
> some other
> >>>>>> timeout which is controlling this? If this is the sum
> of those
> >>>>>> parameters, why would the DGC lease threads live until
> the sum of
> >>>>>> those values? I thought that the lease would expire after the
> >>>>>> leaseValue (10m default).
> >>>>>>
> >>>>>> Can the issue I am observing be caused by a low heap
> pressure on
> >>>>>> the JVM to which the RMI proxies were exported? If it
> fails to
> >>>>>> GC those proxies, even though they are reachable, could that
> >>>>>> cause DGC to continue to retain those proxies on the JVM which
> >>>>>> exported them?
> >>>>>>
> >>>>>> Is there any way to configure DGC to use a thread pool
> or to have
> >>>>>> the leases managed by a single thread?
> >>>>>>
> >>>>>> Is it possible that there is an interaction with the
> useNIO option?
> >>>>>>
> >>>>>> Relevant options that I am using include:
> >>>>>>
> >>>>>> -Dcom.sun.jini.jeri.tcp.useNIO=true
> >>>>>> -Djava.rmi.dgc.leaseValue=30000
> >>>>>> -Dsun.rmi.dgc.checkInterval=15000
> >>>>>> -Dsun.rmi.transport.tcp.connectionPool=true
> >>>>>>
> >>>>>> Thanks in advance,
> >>>>>> Bryan
> >>>>>>
> >>>
> >>>
> >>>
> >>
> >
>
>
Re: DGC threads issue
Posted by Peter Jones <pc...@roundroom.net>.
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 each Exporter. That can quickly turn into a problematic situation in cases like this, where there are lots of "quick" exports followed by termination without "unexport" being done directly as part of the returning context.
>
> Gregg Wonderly
>
> On Jan 13, 2012, at 12:01 AM, Peter Firmstone wrote:
>
>> Is there another way to create an Endpoint per exported object? I'm just thinking, it seems unlikely that Brian's implemented his own Endpoint, but are there any other error conditions or incorrect use scenarios that could produce the same problem?
>>
>> Cheers,
>>
>> Peter.
>>
>> Peter Jones wrote:
>>> Bryan,
>>>
>>> DGC threads should not be per exported object. Generally speaking, they tend to be per endpoint (at which there are one or more remote objects exported). Are you using any sort of custom endpoint implementation? Problems like this can occur when an endpoint implementation doesn't implement Object.equals and hashCode appropriately, so the expected batching of threads (and communication) per endpoint does not occur.
>>>
>>> It might help to see, from a thread dump, exactly which DGC threads are causing this problem. And they are in the server JVM (with all the exported remote objects), not the remote callers' JVM(s)?
>>>
>>> -- Peter
>>>
>>>
>>> On Jan 12, 2012, at 3:45 PM, Tom Hobbs wrote:
>>>
>>>
>>>> Hi Bryan,
>>>>
>>>> Sorry that no one got back to you about this. I'm afraid that I don't
>>>> know the answer to your question, I've copied the dev list into this
>>>> email in case someone who monitors that list (but not this one) has
>>>> any ideas.
>>>>
>>>> Best regards,
>>>>
>>>> Tom
>>>>
>>>> On Thu, Jan 12, 2012 at 2:29 PM, Bryan Thompson <br...@systap.com> wrote:
>>>>
>>>>> Just to follow up on this thread myself. I modified the pattern to return a "thick" future rather than a proxy for the future. This caused the RMI call to wait on the server until the future was done and then sent back the outcome. This "fixed" the DGC memory/thread leak by reducing the number of exported proxies drammatically.
>>>>>
>>>>> In terms of best practices, is distributed DGC simply not useful for exported objects with short life spans? Can it only be used with proxies for relatively long lived services?
>>>>>
>>>>> Thanks,
>>>>> Bryan
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Bryan Thompson
>>>>>> Sent: Tuesday, January 03, 2012 12:06 PM
>>>>>> To: user@river.apache.org
>>>>>> Subject: DGC threads issue
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Background:
>>>>>>
>>>>>> I am seeing what would appear to be one DGC thread allocated
>>>>>> per exported object. This is using River 2.2 and Sun JDK
>>>>>> 1.6.0_17. Relevant configuration parameters are below.
>>>>>>
>>>>>> I am observing problems with the DGC threads not being
>>>>>> retired on a timely basis. The exported objects are proxies
>>>>>> for Futures which are being executed on the service. The
>>>>>> code pattern is such that the proxied Future goes out of
>>>>>> lexical scope quite quickly. E.g.,
>>>>>> rmiCallReturningProxyForFuture().get().
>>>>>>
>>>>>> Under a modest load, a large number of such Futures are
>>>>>> exported which results in a large number of long lived DGC
>>>>>> threads. This turns into a problem for the JVM due to the
>>>>>> stack allocation per thread. Presumably this is not good for
>>>>>> other reasons as well (e.g., scheduling).
>>>>>>
>>>>>> I have tried to override the leaseValue and checkInterval
>>>>>> defaults per the configuration options below. I suspect that
>>>>>> the lease interval is somehow not being obeyed, which is
>>>>>> presumably a problem on my end. However, I can verify that
>>>>>> the configuration values are in fact showing up in
>>>>>> System.getProperties() for at least some of the JVMs involved
>>>>>> (the one which drives the workload and the one that I am
>>>>>> monitoring with the large number of DGC lease threads).
>>>>>>
>>>>>> Some questions:
>>>>>>
>>>>>> Is this one-thread-per-exported proxy the expected behavior
>>>>>> when DGC is requested for the exported object?
>>>>>>
>>>>>> The DGC lease checker threads appear to expire ~14 - 15
>>>>>> minutes after I terminate the process which was originating
>>>>>> the RMI requests. This is close the sum of the default
>>>>>> leaseValue (10m) and checkInterval (5m) parameters, but maybe
>>>>>> there is some other timeout which is controlling this? If
>>>>>> this is the sum of those parameters, why would the DGC lease
>>>>>> threads live until the sum of those values? I thought that
>>>>>> the lease would expire after the leaseValue (10m default).
>>>>>>
>>>>>> Can the issue I am observing be caused by a low heap pressure
>>>>>> on the JVM to which the RMI proxies were exported? If it
>>>>>> fails to GC those proxies, even though they are reachable,
>>>>>> could that cause DGC to continue to retain those proxies on
>>>>>> the JVM which exported them?
>>>>>>
>>>>>> Is there any way to configure DGC to use a thread pool or to
>>>>>> have the leases managed by a single thread?
>>>>>>
>>>>>> Is it possible that there is an interaction with the useNIO option?
>>>>>>
>>>>>> Relevant options that I am using include:
>>>>>>
>>>>>> -Dcom.sun.jini.jeri.tcp.useNIO=true
>>>>>> -Djava.rmi.dgc.leaseValue=30000
>>>>>> -Dsun.rmi.dgc.checkInterval=15000
>>>>>> -Dsun.rmi.transport.tcp.connectionPool=true
>>>>>>
>>>>>> Thanks in advance,
>>>>>> Bryan
>>>>>>
>>>
>>>
>>>
>>
>
Re: DGC threads issue
Posted by Gregg Wonderly <ge...@cox.net>.
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 each Exporter. That can quickly turn into a problematic situation in cases like this, where there are lots of "quick" exports followed by termination without "unexport" being done directly as part of the returning context.
Gregg Wonderly
On Jan 13, 2012, at 12:01 AM, Peter Firmstone wrote:
> Is there another way to create an Endpoint per exported object? I'm just thinking, it seems unlikely that Brian's implemented his own Endpoint, but are there any other error conditions or incorrect use scenarios that could produce the same problem?
>
> Cheers,
>
> Peter.
>
> Peter Jones wrote:
>> Bryan,
>>
>> DGC threads should not be per exported object. Generally speaking, they tend to be per endpoint (at which there are one or more remote objects exported). Are you using any sort of custom endpoint implementation? Problems like this can occur when an endpoint implementation doesn't implement Object.equals and hashCode appropriately, so the expected batching of threads (and communication) per endpoint does not occur.
>>
>> It might help to see, from a thread dump, exactly which DGC threads are causing this problem. And they are in the server JVM (with all the exported remote objects), not the remote callers' JVM(s)?
>>
>> -- Peter
>>
>>
>> On Jan 12, 2012, at 3:45 PM, Tom Hobbs wrote:
>>
>>
>>> Hi Bryan,
>>>
>>> Sorry that no one got back to you about this. I'm afraid that I don't
>>> know the answer to your question, I've copied the dev list into this
>>> email in case someone who monitors that list (but not this one) has
>>> any ideas.
>>>
>>> Best regards,
>>>
>>> Tom
>>>
>>> On Thu, Jan 12, 2012 at 2:29 PM, Bryan Thompson <br...@systap.com> wrote:
>>>
>>>> Just to follow up on this thread myself. I modified the pattern to return a "thick" future rather than a proxy for the future. This caused the RMI call to wait on the server until the future was done and then sent back the outcome. This "fixed" the DGC memory/thread leak by reducing the number of exported proxies drammatically.
>>>>
>>>> In terms of best practices, is distributed DGC simply not useful for exported objects with short life spans? Can it only be used with proxies for relatively long lived services?
>>>>
>>>> Thanks,
>>>> Bryan
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Bryan Thompson
>>>>> Sent: Tuesday, January 03, 2012 12:06 PM
>>>>> To: user@river.apache.org
>>>>> Subject: DGC threads issue
>>>>>
>>>>> Hello,
>>>>>
>>>>> Background:
>>>>>
>>>>> I am seeing what would appear to be one DGC thread allocated
>>>>> per exported object. This is using River 2.2 and Sun JDK
>>>>> 1.6.0_17. Relevant configuration parameters are below.
>>>>>
>>>>> I am observing problems with the DGC threads not being
>>>>> retired on a timely basis. The exported objects are proxies
>>>>> for Futures which are being executed on the service. The
>>>>> code pattern is such that the proxied Future goes out of
>>>>> lexical scope quite quickly. E.g.,
>>>>> rmiCallReturningProxyForFuture().get().
>>>>>
>>>>> Under a modest load, a large number of such Futures are
>>>>> exported which results in a large number of long lived DGC
>>>>> threads. This turns into a problem for the JVM due to the
>>>>> stack allocation per thread. Presumably this is not good for
>>>>> other reasons as well (e.g., scheduling).
>>>>>
>>>>> I have tried to override the leaseValue and checkInterval
>>>>> defaults per the configuration options below. I suspect that
>>>>> the lease interval is somehow not being obeyed, which is
>>>>> presumably a problem on my end. However, I can verify that
>>>>> the configuration values are in fact showing up in
>>>>> System.getProperties() for at least some of the JVMs involved
>>>>> (the one which drives the workload and the one that I am
>>>>> monitoring with the large number of DGC lease threads).
>>>>>
>>>>> Some questions:
>>>>>
>>>>> Is this one-thread-per-exported proxy the expected behavior
>>>>> when DGC is requested for the exported object?
>>>>>
>>>>> The DGC lease checker threads appear to expire ~14 - 15
>>>>> minutes after I terminate the process which was originating
>>>>> the RMI requests. This is close the sum of the default
>>>>> leaseValue (10m) and checkInterval (5m) parameters, but maybe
>>>>> there is some other timeout which is controlling this? If
>>>>> this is the sum of those parameters, why would the DGC lease
>>>>> threads live until the sum of those values? I thought that
>>>>> the lease would expire after the leaseValue (10m default).
>>>>>
>>>>> Can the issue I am observing be caused by a low heap pressure
>>>>> on the JVM to which the RMI proxies were exported? If it
>>>>> fails to GC those proxies, even though they are reachable,
>>>>> could that cause DGC to continue to retain those proxies on
>>>>> the JVM which exported them?
>>>>>
>>>>> Is there any way to configure DGC to use a thread pool or to
>>>>> have the leases managed by a single thread?
>>>>>
>>>>> Is it possible that there is an interaction with the useNIO option?
>>>>>
>>>>> Relevant options that I am using include:
>>>>>
>>>>> -Dcom.sun.jini.jeri.tcp.useNIO=true
>>>>> -Djava.rmi.dgc.leaseValue=30000
>>>>> -Dsun.rmi.dgc.checkInterval=15000
>>>>> -Dsun.rmi.transport.tcp.connectionPool=true
>>>>>
>>>>> Thanks in advance,
>>>>> Bryan
>>>>>
>>
>>
>>
>
Re: DGC threads issue
Posted by Gregg Wonderly <ge...@cox.net>.
It looks like there may be some problems with getting past the v5.4 juniper software release to get to v6.2 on the 5GT because of memory limitations. I finally got the latest 5.4 release installed this afternoon after wasting a bunch of time trying to get the web page interface to "upgrading" to work. I finally had to resort to putting up a tftpd server on my laptop, and using the serial port to tell it to download the software from my laptop and copy it to flash. That worked for the 5.4 upgrade. When I tried that again with the 6.2 release, I got a TFTP error about the file not being readable. I will look at this just a bit more, because I am interested in the IPSEC-VPN support in 6.2.
Gregg
On Jan 13, 2012, at 12:01 AM, Peter Firmstone wrote:
> Is there another way to create an Endpoint per exported object? I'm just thinking, it seems unlikely that Brian's implemented his own Endpoint, but are there any other error conditions or incorrect use scenarios that could produce the same problem?
>
> Cheers,
>
> Peter.
>
> Peter Jones wrote:
>> Bryan,
>>
>> DGC threads should not be per exported object. Generally speaking, they tend to be per endpoint (at which there are one or more remote objects exported). Are you using any sort of custom endpoint implementation? Problems like this can occur when an endpoint implementation doesn't implement Object.equals and hashCode appropriately, so the expected batching of threads (and communication) per endpoint does not occur.
>>
>> It might help to see, from a thread dump, exactly which DGC threads are causing this problem. And they are in the server JVM (with all the exported remote objects), not the remote callers' JVM(s)?
>>
>> -- Peter
>>
>>
>> On Jan 12, 2012, at 3:45 PM, Tom Hobbs wrote:
>>
>>
>>> Hi Bryan,
>>>
>>> Sorry that no one got back to you about this. I'm afraid that I don't
>>> know the answer to your question, I've copied the dev list into this
>>> email in case someone who monitors that list (but not this one) has
>>> any ideas.
>>>
>>> Best regards,
>>>
>>> Tom
>>>
>>> On Thu, Jan 12, 2012 at 2:29 PM, Bryan Thompson <br...@systap.com> wrote:
>>>
>>>> Just to follow up on this thread myself. I modified the pattern to return a "thick" future rather than a proxy for the future. This caused the RMI call to wait on the server until the future was done and then sent back the outcome. This "fixed" the DGC memory/thread leak by reducing the number of exported proxies drammatically.
>>>>
>>>> In terms of best practices, is distributed DGC simply not useful for exported objects with short life spans? Can it only be used with proxies for relatively long lived services?
>>>>
>>>> Thanks,
>>>> Bryan
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Bryan Thompson
>>>>> Sent: Tuesday, January 03, 2012 12:06 PM
>>>>> To: user@river.apache.org
>>>>> Subject: DGC threads issue
>>>>>
>>>>> Hello,
>>>>>
>>>>> Background:
>>>>>
>>>>> I am seeing what would appear to be one DGC thread allocated
>>>>> per exported object. This is using River 2.2 and Sun JDK
>>>>> 1.6.0_17. Relevant configuration parameters are below.
>>>>>
>>>>> I am observing problems with the DGC threads not being
>>>>> retired on a timely basis. The exported objects are proxies
>>>>> for Futures which are being executed on the service. The
>>>>> code pattern is such that the proxied Future goes out of
>>>>> lexical scope quite quickly. E.g.,
>>>>> rmiCallReturningProxyForFuture().get().
>>>>>
>>>>> Under a modest load, a large number of such Futures are
>>>>> exported which results in a large number of long lived DGC
>>>>> threads. This turns into a problem for the JVM due to the
>>>>> stack allocation per thread. Presumably this is not good for
>>>>> other reasons as well (e.g., scheduling).
>>>>>
>>>>> I have tried to override the leaseValue and checkInterval
>>>>> defaults per the configuration options below. I suspect that
>>>>> the lease interval is somehow not being obeyed, which is
>>>>> presumably a problem on my end. However, I can verify that
>>>>> the configuration values are in fact showing up in
>>>>> System.getProperties() for at least some of the JVMs involved
>>>>> (the one which drives the workload and the one that I am
>>>>> monitoring with the large number of DGC lease threads).
>>>>>
>>>>> Some questions:
>>>>>
>>>>> Is this one-thread-per-exported proxy the expected behavior
>>>>> when DGC is requested for the exported object?
>>>>>
>>>>> The DGC lease checker threads appear to expire ~14 - 15
>>>>> minutes after I terminate the process which was originating
>>>>> the RMI requests. This is close the sum of the default
>>>>> leaseValue (10m) and checkInterval (5m) parameters, but maybe
>>>>> there is some other timeout which is controlling this? If
>>>>> this is the sum of those parameters, why would the DGC lease
>>>>> threads live until the sum of those values? I thought that
>>>>> the lease would expire after the leaseValue (10m default).
>>>>>
>>>>> Can the issue I am observing be caused by a low heap pressure
>>>>> on the JVM to which the RMI proxies were exported? If it
>>>>> fails to GC those proxies, even though they are reachable,
>>>>> could that cause DGC to continue to retain those proxies on
>>>>> the JVM which exported them?
>>>>>
>>>>> Is there any way to configure DGC to use a thread pool or to
>>>>> have the leases managed by a single thread?
>>>>>
>>>>> Is it possible that there is an interaction with the useNIO option?
>>>>>
>>>>> Relevant options that I am using include:
>>>>>
>>>>> -Dcom.sun.jini.jeri.tcp.useNIO=true
>>>>> -Djava.rmi.dgc.leaseValue=30000
>>>>> -Dsun.rmi.dgc.checkInterval=15000
>>>>> -Dsun.rmi.transport.tcp.connectionPool=true
>>>>>
>>>>> Thanks in advance,
>>>>> Bryan
>>>>>
>>
>>
>>
>
Re: DGC threads issue
Posted by Peter Firmstone <ji...@zeus.net.au>.
Is there another way to create an Endpoint per exported object? I'm
just thinking, it seems unlikely that Brian's implemented his own
Endpoint, but are there any other error conditions or incorrect use
scenarios that could produce the same problem?
Cheers,
Peter.
Peter Jones wrote:
> Bryan,
>
> DGC threads should not be per exported object. Generally speaking, they tend to be per endpoint (at which there are one or more remote objects exported). Are you using any sort of custom endpoint implementation? Problems like this can occur when an endpoint implementation doesn't implement Object.equals and hashCode appropriately, so the expected batching of threads (and communication) per endpoint does not occur.
>
> It might help to see, from a thread dump, exactly which DGC threads are causing this problem. And they are in the server JVM (with all the exported remote objects), not the remote callers' JVM(s)?
>
> -- Peter
>
>
> On Jan 12, 2012, at 3:45 PM, Tom Hobbs wrote:
>
>
>> Hi Bryan,
>>
>> Sorry that no one got back to you about this. I'm afraid that I don't
>> know the answer to your question, I've copied the dev list into this
>> email in case someone who monitors that list (but not this one) has
>> any ideas.
>>
>> Best regards,
>>
>> Tom
>>
>> On Thu, Jan 12, 2012 at 2:29 PM, Bryan Thompson <br...@systap.com> wrote:
>>
>>> Just to follow up on this thread myself. I modified the pattern to return a "thick" future rather than a proxy for the future. This caused the RMI call to wait on the server until the future was done and then sent back the outcome. This "fixed" the DGC memory/thread leak by reducing the number of exported proxies drammatically.
>>>
>>> In terms of best practices, is distributed DGC simply not useful for exported objects with short life spans? Can it only be used with proxies for relatively long lived services?
>>>
>>> Thanks,
>>> Bryan
>>>
>>>
>>>> -----Original Message-----
>>>> From: Bryan Thompson
>>>> Sent: Tuesday, January 03, 2012 12:06 PM
>>>> To: user@river.apache.org
>>>> Subject: DGC threads issue
>>>>
>>>> Hello,
>>>>
>>>> Background:
>>>>
>>>> I am seeing what would appear to be one DGC thread allocated
>>>> per exported object. This is using River 2.2 and Sun JDK
>>>> 1.6.0_17. Relevant configuration parameters are below.
>>>>
>>>> I am observing problems with the DGC threads not being
>>>> retired on a timely basis. The exported objects are proxies
>>>> for Futures which are being executed on the service. The
>>>> code pattern is such that the proxied Future goes out of
>>>> lexical scope quite quickly. E.g.,
>>>> rmiCallReturningProxyForFuture().get().
>>>>
>>>> Under a modest load, a large number of such Futures are
>>>> exported which results in a large number of long lived DGC
>>>> threads. This turns into a problem for the JVM due to the
>>>> stack allocation per thread. Presumably this is not good for
>>>> other reasons as well (e.g., scheduling).
>>>>
>>>> I have tried to override the leaseValue and checkInterval
>>>> defaults per the configuration options below. I suspect that
>>>> the lease interval is somehow not being obeyed, which is
>>>> presumably a problem on my end. However, I can verify that
>>>> the configuration values are in fact showing up in
>>>> System.getProperties() for at least some of the JVMs involved
>>>> (the one which drives the workload and the one that I am
>>>> monitoring with the large number of DGC lease threads).
>>>>
>>>> Some questions:
>>>>
>>>> Is this one-thread-per-exported proxy the expected behavior
>>>> when DGC is requested for the exported object?
>>>>
>>>> The DGC lease checker threads appear to expire ~14 - 15
>>>> minutes after I terminate the process which was originating
>>>> the RMI requests. This is close the sum of the default
>>>> leaseValue (10m) and checkInterval (5m) parameters, but maybe
>>>> there is some other timeout which is controlling this? If
>>>> this is the sum of those parameters, why would the DGC lease
>>>> threads live until the sum of those values? I thought that
>>>> the lease would expire after the leaseValue (10m default).
>>>>
>>>> Can the issue I am observing be caused by a low heap pressure
>>>> on the JVM to which the RMI proxies were exported? If it
>>>> fails to GC those proxies, even though they are reachable,
>>>> could that cause DGC to continue to retain those proxies on
>>>> the JVM which exported them?
>>>>
>>>> Is there any way to configure DGC to use a thread pool or to
>>>> have the leases managed by a single thread?
>>>>
>>>> Is it possible that there is an interaction with the useNIO option?
>>>>
>>>> Relevant options that I am using include:
>>>>
>>>> -Dcom.sun.jini.jeri.tcp.useNIO=true
>>>> -Djava.rmi.dgc.leaseValue=30000
>>>> -Dsun.rmi.dgc.checkInterval=15000
>>>> -Dsun.rmi.transport.tcp.connectionPool=true
>>>>
>>>> Thanks in advance,
>>>> Bryan
>>>>
>
>
>
Re: DGC threads issue
Posted by Peter Jones <pc...@roundroom.net>.
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 in Thread.run().
>
> The stacks below are from a capture in yourkit that I had on hand from when I was investigating this problem. The workload had been removed from the service but the leases had not yet expired.
>
> Thanks,
> Bryan
>
> Stacks at 09:16:02 AM (uptime 1:48:56)
>
>
> (JSK) ConnectionManager.Reaper [SLEEPING] CPU time: 0:00
> java.lang.Thread.sleep(long)
> net.jini.jeri.connection.ConnectionManager$Reaper.run()
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Threa
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> (JSK) DGC Lease Checker [SLEEPING] CPU time: 0:hread.run()
>
>
>
> com.bigdata.journal.ConcurrencyManager.writeService48 [WAITING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> com.bigdata.journal.ConcurrencyManager.writeService49 [WAITING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
> com.bigdata.journal.ConcurrencyManager.writeService5 [WAITING] CPU time: 0:00
> java.lang.Thread.run()
>
>
>
>> -----Original Message-----
>> From: Peter Jones [mailto:pcj@roundroom.net]
>> Sent: Friday, January 13, 2012 9:31 AM
>> To: user@river.apache.org
>> Cc: dev@river.apache.org
>> Subject: Re: DGC threads issue
>>
>> 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 implementation
>> has changed recently. But I gather that Peter F. may have
>> identified the root cause.
>>
>> Cheers,
>>
>> -- Peter
>>
>>
> <DGCThreadDump.txt>
RE: DGC threads issue
Posted by Bryan Thompson <br...@systap.com>.
Peter,
There is very little information in there. Basically a whole lot of "DGC Lease Checker" threads all sleeping in Thread.run().
The stacks below are from a capture in yourkit that I had on hand from when I was investigating this problem. The workload had been removed from the service but the leases had not yet expired.
Thanks,
Bryan
Stacks at 09:16:02 AM (uptime 1:48:56)
(JSK) ConnectionManager.Reaper [SLEEPING] CPU time: 0:00
java.lang.Thread.sleep(long)
net.jini.jeri.connection.ConnectionManager$Reaper.run()
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Threa
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:hread.run()
com.bigdata.journal.ConcurrencyManager.writeService48 [WAITING] CPU time: 0:00
java.lang.Thread.run()
com.bigdata.journal.ConcurrencyManager.writeService49 [WAITING] CPU time: 0:00
java.lang.Thread.run()
com.bigdata.journal.ConcurrencyManager.writeService5 [WAITING] CPU time: 0:00
java.lang.Thread.run()
> -----Original Message-----
> From: Peter Jones [mailto:pcj@roundroom.net]
> Sent: Friday, January 13, 2012 9:31 AM
> To: user@river.apache.org
> Cc: dev@river.apache.org
> Subject: Re: DGC threads issue
>
> 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 implementation
> has changed recently. But I gather that Peter F. may have
> identified the root cause.
>
> Cheers,
>
> -- Peter
>
>
RE: DGC threads issue
Posted by Bryan Thompson <br...@systap.com>.
Peter,
There is very little information in there. Basically a whole lot of "DGC Lease Checker" threads all sleeping in Thread.run().
The stacks below are from a capture in yourkit that I had on hand from when I was investigating this problem. The workload had been removed from the service but the leases had not yet expired.
Thanks,
Bryan
Stacks at 09:16:02 AM (uptime 1:48:56)
(JSK) ConnectionManager.Reaper [SLEEPING] CPU time: 0:00
java.lang.Thread.sleep(long)
net.jini.jeri.connection.ConnectionManager$Reaper.run()
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Threa
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:00
java.lang.Thread.run()
(JSK) DGC Lease Checker [SLEEPING] CPU time: 0:hread.run()
com.bigdata.journal.ConcurrencyManager.writeService48 [WAITING] CPU time: 0:00
java.lang.Thread.run()
com.bigdata.journal.ConcurrencyManager.writeService49 [WAITING] CPU time: 0:00
java.lang.Thread.run()
com.bigdata.journal.ConcurrencyManager.writeService5 [WAITING] CPU time: 0:00
java.lang.Thread.run()
> -----Original Message-----
> From: Peter Jones [mailto:pcj@roundroom.net]
> Sent: Friday, January 13, 2012 9:31 AM
> To: user@river.apache.org
> Cc: dev@river.apache.org
> Subject: Re: DGC threads issue
>
> 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 implementation
> has changed recently. But I gather that Peter F. may have
> identified the root cause.
>
> Cheers,
>
> -- Peter
>
>
Re: DGC threads issue
Posted by Peter Jones <pc...@roundroom.net>.
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 implementation has changed recently. But I gather that Peter F. may have identified the root cause.
Cheers,
-- Peter
On Jan 13, 2012, at 7:28 AM, Bryan Thompson wrote:
> Peter,
>
> The DGC Threads are in the server JVM. They are nearly all for the exported Futures.
>
> Thanks,
> Bryan
>
>> -----Original Message-----
>> From: Peter Jones [mailto:pcj@roundroom.net]
>> Sent: Friday, January 13, 2012 12:04 AM
>> To: user@river.apache.org
>> Cc: dev@river.apache.org
>> Subject: Re: DGC threads issue
>>
>> Bryan,
>>
>> DGC threads should not be per exported object. Generally
>> speaking, they tend to be per endpoint (at which there are
>> one or more remote objects exported). Are you using any sort
>> of custom endpoint implementation? Problems like this can
>> occur when an endpoint implementation doesn't implement
>> Object.equals and hashCode appropriately, so the expected
>> batching of threads (and communication) per endpoint does not occur.
>>
>> It might help to see, from a thread dump, exactly which DGC
>> threads are causing this problem. And they are in the server
>> JVM (with all the exported remote objects), not the remote
>> callers' JVM(s)?
>>
>> -- Peter
>>
>>
>> On Jan 12, 2012, at 3:45 PM, Tom Hobbs wrote:
>>
>>> Hi Bryan,
>>>
>>> Sorry that no one got back to you about this. I'm afraid
>> that I don't
>>> know the answer to your question, I've copied the dev list
>> into this
>>> email in case someone who monitors that list (but not this one) has
>>> any ideas.
>>>
>>> Best regards,
>>>
>>> Tom
>>>
>>> On Thu, Jan 12, 2012 at 2:29 PM, Bryan Thompson
>> <br...@systap.com> wrote:
>>>> Just to follow up on this thread myself. I modified the
>> pattern to return a "thick" future rather than a proxy for
>> the future. This caused the RMI call to wait on the server
>> until the future was done and then sent back the outcome.
>> This "fixed" the DGC memory/thread leak by reducing the
>> number of exported proxies drammatically.
>>>>
>>>> In terms of best practices, is distributed DGC simply not
>> useful for exported objects with short life spans? Can it
>> only be used with proxies for relatively long lived services?
>>>>
>>>> Thanks,
>>>> Bryan
>>>>
>>>>> -----Original Message-----
>>>>> From: Bryan Thompson
>>>>> Sent: Tuesday, January 03, 2012 12:06 PM
>>>>> To: user@river.apache.org
>>>>> Subject: DGC threads issue
>>>>>
>>>>> Hello,
>>>>>
>>>>> Background:
>>>>>
>>>>> I am seeing what would appear to be one DGC thread allocated per
>>>>> exported object. This is using River 2.2 and Sun JDK 1.6.0_17.
>>>>> Relevant configuration parameters are below.
>>>>>
>>>>> I am observing problems with the DGC threads not being
>> retired on a
>>>>> timely basis. The exported objects are proxies for Futures which
>>>>> are being executed on the service. The code pattern is such that
>>>>> the proxied Future goes out of lexical scope quite
>> quickly. E.g.,
>>>>> rmiCallReturningProxyForFuture().get().
>>>>>
>>>>> Under a modest load, a large number of such Futures are exported
>>>>> which results in a large number of long lived DGC threads. This
>>>>> turns into a problem for the JVM due to the stack allocation per
>>>>> thread. Presumably this is not good for other reasons as well
>>>>> (e.g., scheduling).
>>>>>
>>>>> I have tried to override the leaseValue and checkInterval
>> defaults
>>>>> per the configuration options below. I suspect that the lease
>>>>> interval is somehow not being obeyed, which is presumably
>> a problem
>>>>> on my end. However, I can verify that the configuration
>> values are
>>>>> in fact showing up in
>>>>> System.getProperties() for at least some of the JVMs
>> involved (the
>>>>> one which drives the workload and the one that I am
>> monitoring with
>>>>> the large number of DGC lease threads).
>>>>>
>>>>> Some questions:
>>>>>
>>>>> Is this one-thread-per-exported proxy the expected
>> behavior when DGC
>>>>> is requested for the exported object?
>>>>>
>>>>> The DGC lease checker threads appear to expire ~14 - 15 minutes
>>>>> after I terminate the process which was originating the RMI
>>>>> requests. This is close the sum of the default
>> leaseValue (10m) and
>>>>> checkInterval (5m) parameters, but maybe there is some
>> other timeout
>>>>> which is controlling this? If this is the sum of those
>> parameters,
>>>>> why would the DGC lease threads live until the sum of
>> those values?
>>>>> I thought that the lease would expire after the leaseValue (10m
>>>>> default).
>>>>>
>>>>> Can the issue I am observing be caused by a low heap
>> pressure on the
>>>>> JVM to which the RMI proxies were exported? If it fails
>> to GC those
>>>>> proxies, even though they are reachable, could that cause DGC to
>>>>> continue to retain those proxies on the JVM which exported them?
>>>>>
>>>>> Is there any way to configure DGC to use a thread pool or to have
>>>>> the leases managed by a single thread?
>>>>>
>>>>> Is it possible that there is an interaction with the
>> useNIO option?
>>>>>
>>>>> Relevant options that I am using include:
>>>>>
>>>>> -Dcom.sun.jini.jeri.tcp.useNIO=true
>>>>> -Djava.rmi.dgc.leaseValue=30000
>>>>> -Dsun.rmi.dgc.checkInterval=15000
>>>>> -Dsun.rmi.transport.tcp.connectionPool=true
>>>>>
>>>>> Thanks in advance,
>>>>> Bryan
>>
Re: DGC threads issue
Posted by Peter Jones <pc...@roundroom.net>.
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 implementation has changed recently. But I gather that Peter F. may have identified the root cause.
Cheers,
-- Peter
On Jan 13, 2012, at 7:28 AM, Bryan Thompson wrote:
> Peter,
>
> The DGC Threads are in the server JVM. They are nearly all for the exported Futures.
>
> Thanks,
> Bryan
>
>> -----Original Message-----
>> From: Peter Jones [mailto:pcj@roundroom.net]
>> Sent: Friday, January 13, 2012 12:04 AM
>> To: user@river.apache.org
>> Cc: dev@river.apache.org
>> Subject: Re: DGC threads issue
>>
>> Bryan,
>>
>> DGC threads should not be per exported object. Generally
>> speaking, they tend to be per endpoint (at which there are
>> one or more remote objects exported). Are you using any sort
>> of custom endpoint implementation? Problems like this can
>> occur when an endpoint implementation doesn't implement
>> Object.equals and hashCode appropriately, so the expected
>> batching of threads (and communication) per endpoint does not occur.
>>
>> It might help to see, from a thread dump, exactly which DGC
>> threads are causing this problem. And they are in the server
>> JVM (with all the exported remote objects), not the remote
>> callers' JVM(s)?
>>
>> -- Peter
>>
>>
>> On Jan 12, 2012, at 3:45 PM, Tom Hobbs wrote:
>>
>>> Hi Bryan,
>>>
>>> Sorry that no one got back to you about this. I'm afraid
>> that I don't
>>> know the answer to your question, I've copied the dev list
>> into this
>>> email in case someone who monitors that list (but not this one) has
>>> any ideas.
>>>
>>> Best regards,
>>>
>>> Tom
>>>
>>> On Thu, Jan 12, 2012 at 2:29 PM, Bryan Thompson
>> <br...@systap.com> wrote:
>>>> Just to follow up on this thread myself. I modified the
>> pattern to return a "thick" future rather than a proxy for
>> the future. This caused the RMI call to wait on the server
>> until the future was done and then sent back the outcome.
>> This "fixed" the DGC memory/thread leak by reducing the
>> number of exported proxies drammatically.
>>>>
>>>> In terms of best practices, is distributed DGC simply not
>> useful for exported objects with short life spans? Can it
>> only be used with proxies for relatively long lived services?
>>>>
>>>> Thanks,
>>>> Bryan
>>>>
>>>>> -----Original Message-----
>>>>> From: Bryan Thompson
>>>>> Sent: Tuesday, January 03, 2012 12:06 PM
>>>>> To: user@river.apache.org
>>>>> Subject: DGC threads issue
>>>>>
>>>>> Hello,
>>>>>
>>>>> Background:
>>>>>
>>>>> I am seeing what would appear to be one DGC thread allocated per
>>>>> exported object. This is using River 2.2 and Sun JDK 1.6.0_17.
>>>>> Relevant configuration parameters are below.
>>>>>
>>>>> I am observing problems with the DGC threads not being
>> retired on a
>>>>> timely basis. The exported objects are proxies for Futures which
>>>>> are being executed on the service. The code pattern is such that
>>>>> the proxied Future goes out of lexical scope quite
>> quickly. E.g.,
>>>>> rmiCallReturningProxyForFuture().get().
>>>>>
>>>>> Under a modest load, a large number of such Futures are exported
>>>>> which results in a large number of long lived DGC threads. This
>>>>> turns into a problem for the JVM due to the stack allocation per
>>>>> thread. Presumably this is not good for other reasons as well
>>>>> (e.g., scheduling).
>>>>>
>>>>> I have tried to override the leaseValue and checkInterval
>> defaults
>>>>> per the configuration options below. I suspect that the lease
>>>>> interval is somehow not being obeyed, which is presumably
>> a problem
>>>>> on my end. However, I can verify that the configuration
>> values are
>>>>> in fact showing up in
>>>>> System.getProperties() for at least some of the JVMs
>> involved (the
>>>>> one which drives the workload and the one that I am
>> monitoring with
>>>>> the large number of DGC lease threads).
>>>>>
>>>>> Some questions:
>>>>>
>>>>> Is this one-thread-per-exported proxy the expected
>> behavior when DGC
>>>>> is requested for the exported object?
>>>>>
>>>>> The DGC lease checker threads appear to expire ~14 - 15 minutes
>>>>> after I terminate the process which was originating the RMI
>>>>> requests. This is close the sum of the default
>> leaseValue (10m) and
>>>>> checkInterval (5m) parameters, but maybe there is some
>> other timeout
>>>>> which is controlling this? If this is the sum of those
>> parameters,
>>>>> why would the DGC lease threads live until the sum of
>> those values?
>>>>> I thought that the lease would expire after the leaseValue (10m
>>>>> default).
>>>>>
>>>>> Can the issue I am observing be caused by a low heap
>> pressure on the
>>>>> JVM to which the RMI proxies were exported? If it fails
>> to GC those
>>>>> proxies, even though they are reachable, could that cause DGC to
>>>>> continue to retain those proxies on the JVM which exported them?
>>>>>
>>>>> Is there any way to configure DGC to use a thread pool or to have
>>>>> the leases managed by a single thread?
>>>>>
>>>>> Is it possible that there is an interaction with the
>> useNIO option?
>>>>>
>>>>> Relevant options that I am using include:
>>>>>
>>>>> -Dcom.sun.jini.jeri.tcp.useNIO=true
>>>>> -Djava.rmi.dgc.leaseValue=30000
>>>>> -Dsun.rmi.dgc.checkInterval=15000
>>>>> -Dsun.rmi.transport.tcp.connectionPool=true
>>>>>
>>>>> Thanks in advance,
>>>>> Bryan
>>
RE: DGC threads issue
Posted by Bryan Thompson <br...@systap.com>.
Simon,
No. The standard TcpServerEndpoint.
Thanks,
Bryan
> -----Original Message-----
> From: Simon IJskes - QCG [mailto:simon@qcg.nl]
> Sent: Friday, January 13, 2012 8:26 AM
> To: user@river.apache.org
> Subject: Re: DGC threads issue
>
> Did you use SocketFactory ?
>
> http://river.apache.org/user-guide-socketfactories.html
>
> Gr. Sim
>
> On 13-01-12 13:28, Bryan Thompson wrote:
> > Peter,
> >
> > The DGC Threads are in the server JVM. They are nearly all
> for the exported Futures.
> >
> > Thanks,
> > Bryan
> >
> >> -----Original Message-----
> >> From: Peter Jones [mailto:pcj@roundroom.net]
> >> Sent: Friday, January 13, 2012 12:04 AM
> >> To: user@river.apache.org
> >> Cc: dev@river.apache.org
> >> Subject: Re: DGC threads issue
> >>
> >> Bryan,
> >>
> >> DGC threads should not be per exported object. Generally
> speaking,
> >> they tend to be per endpoint (at which there are one or
> more remote
> >> objects exported). Are you using any sort of custom endpoint
> >> implementation? Problems like this can occur when an endpoint
> >> implementation doesn't implement Object.equals and hashCode
> >> appropriately, so the expected batching of threads (and
> >> communication) per endpoint does not occur.
> >>
> >> It might help to see, from a thread dump, exactly which
> DGC threads
> >> are causing this problem. And they are in the server JVM
> (with all
> >> the exported remote objects), not the remote callers' JVM(s)?
> >>
> >> -- Peter
> >>
> >>
> >> On Jan 12, 2012, at 3:45 PM, Tom Hobbs wrote:
> >>
> >>> Hi Bryan,
> >>>
> >>> Sorry that no one got back to you about this. I'm afraid
> >> that I don't
> >>> know the answer to your question, I've copied the dev list
> >> into this
> >>> email in case someone who monitors that list (but not
> this one) has
> >>> any ideas.
> >>>
> >>> Best regards,
> >>>
> >>> Tom
> >>>
> >>> On Thu, Jan 12, 2012 at 2:29 PM, Bryan Thompson
> >> <br...@systap.com> wrote:
> >>>> Just to follow up on this thread myself. I modified the
> >> pattern to return a "thick" future rather than a proxy for the
> >> future. This caused the RMI call to wait on the server until the
> >> future was done and then sent back the outcome.
> >> This "fixed" the DGC memory/thread leak by reducing the number of
> >> exported proxies drammatically.
> >>>>
> >>>> In terms of best practices, is distributed DGC simply not
> >> useful for exported objects with short life spans? Can it only be
> >> used with proxies for relatively long lived services?
> >>>>
> >>>> Thanks,
> >>>> Bryan
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Bryan Thompson
> >>>>> Sent: Tuesday, January 03, 2012 12:06 PM
> >>>>> To: user@river.apache.org
> >>>>> Subject: DGC threads issue
> >>>>>
> >>>>> Hello,
> >>>>>
> >>>>> Background:
> >>>>>
> >>>>> I am seeing what would appear to be one DGC thread
> allocated per
> >>>>> exported object. This is using River 2.2 and Sun JDK 1.6.0_17.
> >>>>> Relevant configuration parameters are below.
> >>>>>
> >>>>> I am observing problems with the DGC threads not being
> >> retired on a
> >>>>> timely basis. The exported objects are proxies for
> Futures which
> >>>>> are being executed on the service. The code pattern is
> such that
> >>>>> the proxied Future goes out of lexical scope quite
> >> quickly. E.g.,
> >>>>> rmiCallReturningProxyForFuture().get().
> >>>>>
> >>>>> Under a modest load, a large number of such Futures are
> exported
> >>>>> which results in a large number of long lived DGC
> threads. This
> >>>>> turns into a problem for the JVM due to the stack
> allocation per
> >>>>> thread. Presumably this is not good for other reasons as well
> >>>>> (e.g., scheduling).
> >>>>>
> >>>>> I have tried to override the leaseValue and checkInterval
> >> defaults
> >>>>> per the configuration options below. I suspect that the lease
> >>>>> interval is somehow not being obeyed, which is presumably
> >> a problem
> >>>>> on my end. However, I can verify that the configuration
> >> values are
> >>>>> in fact showing up in
> >>>>> System.getProperties() for at least some of the JVMs
> >> involved (the
> >>>>> one which drives the workload and the one that I am
> >> monitoring with
> >>>>> the large number of DGC lease threads).
> >>>>>
> >>>>> Some questions:
> >>>>>
> >>>>> Is this one-thread-per-exported proxy the expected
> >> behavior when DGC
> >>>>> is requested for the exported object?
> >>>>>
> >>>>> The DGC lease checker threads appear to expire ~14 - 15 minutes
> >>>>> after I terminate the process which was originating the RMI
> >>>>> requests. This is close the sum of the default
> >> leaseValue (10m) and
> >>>>> checkInterval (5m) parameters, but maybe there is some
> >> other timeout
> >>>>> which is controlling this? If this is the sum of those
> >> parameters,
> >>>>> why would the DGC lease threads live until the sum of
> >> those values?
> >>>>> I thought that the lease would expire after the leaseValue (10m
> >>>>> default).
> >>>>>
> >>>>> Can the issue I am observing be caused by a low heap
> >> pressure on the
> >>>>> JVM to which the RMI proxies were exported? If it fails
> >> to GC those
> >>>>> proxies, even though they are reachable, could that
> cause DGC to
> >>>>> continue to retain those proxies on the JVM which exported them?
> >>>>>
> >>>>> Is there any way to configure DGC to use a thread pool
> or to have
> >>>>> the leases managed by a single thread?
> >>>>>
> >>>>> Is it possible that there is an interaction with the
> >> useNIO option?
> >>>>>
> >>>>> Relevant options that I am using include:
> >>>>>
> >>>>> -Dcom.sun.jini.jeri.tcp.useNIO=true
> >>>>> -Djava.rmi.dgc.leaseValue=30000
> >>>>> -Dsun.rmi.dgc.checkInterval=15000
> >>>>> -Dsun.rmi.transport.tcp.connectionPool=true
> >>>>>
> >>>>> Thanks in advance,
> >>>>> Bryan
> >>
>
>
> --
> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
>
Re: DGC threads issue
Posted by Simon IJskes - QCG <si...@qcg.nl>.
Did you use SocketFactory ?
http://river.apache.org/user-guide-socketfactories.html
Gr. Sim
On 13-01-12 13:28, Bryan Thompson wrote:
> Peter,
>
> The DGC Threads are in the server JVM. They are nearly all for the exported Futures.
>
> Thanks,
> Bryan
>
>> -----Original Message-----
>> From: Peter Jones [mailto:pcj@roundroom.net]
>> Sent: Friday, January 13, 2012 12:04 AM
>> To: user@river.apache.org
>> Cc: dev@river.apache.org
>> Subject: Re: DGC threads issue
>>
>> Bryan,
>>
>> DGC threads should not be per exported object. Generally
>> speaking, they tend to be per endpoint (at which there are
>> one or more remote objects exported). Are you using any sort
>> of custom endpoint implementation? Problems like this can
>> occur when an endpoint implementation doesn't implement
>> Object.equals and hashCode appropriately, so the expected
>> batching of threads (and communication) per endpoint does not occur.
>>
>> It might help to see, from a thread dump, exactly which DGC
>> threads are causing this problem. And they are in the server
>> JVM (with all the exported remote objects), not the remote
>> callers' JVM(s)?
>>
>> -- Peter
>>
>>
>> On Jan 12, 2012, at 3:45 PM, Tom Hobbs wrote:
>>
>>> Hi Bryan,
>>>
>>> Sorry that no one got back to you about this. I'm afraid
>> that I don't
>>> know the answer to your question, I've copied the dev list
>> into this
>>> email in case someone who monitors that list (but not this one) has
>>> any ideas.
>>>
>>> Best regards,
>>>
>>> Tom
>>>
>>> On Thu, Jan 12, 2012 at 2:29 PM, Bryan Thompson
>> <br...@systap.com> wrote:
>>>> Just to follow up on this thread myself. I modified the
>> pattern to return a "thick" future rather than a proxy for
>> the future. This caused the RMI call to wait on the server
>> until the future was done and then sent back the outcome.
>> This "fixed" the DGC memory/thread leak by reducing the
>> number of exported proxies drammatically.
>>>>
>>>> In terms of best practices, is distributed DGC simply not
>> useful for exported objects with short life spans? Can it
>> only be used with proxies for relatively long lived services?
>>>>
>>>> Thanks,
>>>> Bryan
>>>>
>>>>> -----Original Message-----
>>>>> From: Bryan Thompson
>>>>> Sent: Tuesday, January 03, 2012 12:06 PM
>>>>> To: user@river.apache.org
>>>>> Subject: DGC threads issue
>>>>>
>>>>> Hello,
>>>>>
>>>>> Background:
>>>>>
>>>>> I am seeing what would appear to be one DGC thread allocated per
>>>>> exported object. This is using River 2.2 and Sun JDK 1.6.0_17.
>>>>> Relevant configuration parameters are below.
>>>>>
>>>>> I am observing problems with the DGC threads not being
>> retired on a
>>>>> timely basis. The exported objects are proxies for Futures which
>>>>> are being executed on the service. The code pattern is such that
>>>>> the proxied Future goes out of lexical scope quite
>> quickly. E.g.,
>>>>> rmiCallReturningProxyForFuture().get().
>>>>>
>>>>> Under a modest load, a large number of such Futures are exported
>>>>> which results in a large number of long lived DGC threads. This
>>>>> turns into a problem for the JVM due to the stack allocation per
>>>>> thread. Presumably this is not good for other reasons as well
>>>>> (e.g., scheduling).
>>>>>
>>>>> I have tried to override the leaseValue and checkInterval
>> defaults
>>>>> per the configuration options below. I suspect that the lease
>>>>> interval is somehow not being obeyed, which is presumably
>> a problem
>>>>> on my end. However, I can verify that the configuration
>> values are
>>>>> in fact showing up in
>>>>> System.getProperties() for at least some of the JVMs
>> involved (the
>>>>> one which drives the workload and the one that I am
>> monitoring with
>>>>> the large number of DGC lease threads).
>>>>>
>>>>> Some questions:
>>>>>
>>>>> Is this one-thread-per-exported proxy the expected
>> behavior when DGC
>>>>> is requested for the exported object?
>>>>>
>>>>> The DGC lease checker threads appear to expire ~14 - 15 minutes
>>>>> after I terminate the process which was originating the RMI
>>>>> requests. This is close the sum of the default
>> leaseValue (10m) and
>>>>> checkInterval (5m) parameters, but maybe there is some
>> other timeout
>>>>> which is controlling this? If this is the sum of those
>> parameters,
>>>>> why would the DGC lease threads live until the sum of
>> those values?
>>>>> I thought that the lease would expire after the leaseValue (10m
>>>>> default).
>>>>>
>>>>> Can the issue I am observing be caused by a low heap
>> pressure on the
>>>>> JVM to which the RMI proxies were exported? If it fails
>> to GC those
>>>>> proxies, even though they are reachable, could that cause DGC to
>>>>> continue to retain those proxies on the JVM which exported them?
>>>>>
>>>>> Is there any way to configure DGC to use a thread pool or to have
>>>>> the leases managed by a single thread?
>>>>>
>>>>> Is it possible that there is an interaction with the
>> useNIO option?
>>>>>
>>>>> Relevant options that I am using include:
>>>>>
>>>>> -Dcom.sun.jini.jeri.tcp.useNIO=true
>>>>> -Djava.rmi.dgc.leaseValue=30000
>>>>> -Dsun.rmi.dgc.checkInterval=15000
>>>>> -Dsun.rmi.transport.tcp.connectionPool=true
>>>>>
>>>>> Thanks in advance,
>>>>> Bryan
>>
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
RE: DGC threads issue
Posted by Bryan Thompson <br...@systap.com>.
Peter,
The DGC Threads are in the server JVM. They are nearly all for the exported Futures.
Thanks,
Bryan
> -----Original Message-----
> From: Peter Jones [mailto:pcj@roundroom.net]
> Sent: Friday, January 13, 2012 12:04 AM
> To: user@river.apache.org
> Cc: dev@river.apache.org
> Subject: Re: DGC threads issue
>
> Bryan,
>
> DGC threads should not be per exported object. Generally
> speaking, they tend to be per endpoint (at which there are
> one or more remote objects exported). Are you using any sort
> of custom endpoint implementation? Problems like this can
> occur when an endpoint implementation doesn't implement
> Object.equals and hashCode appropriately, so the expected
> batching of threads (and communication) per endpoint does not occur.
>
> It might help to see, from a thread dump, exactly which DGC
> threads are causing this problem. And they are in the server
> JVM (with all the exported remote objects), not the remote
> callers' JVM(s)?
>
> -- Peter
>
>
> On Jan 12, 2012, at 3:45 PM, Tom Hobbs wrote:
>
> > Hi Bryan,
> >
> > Sorry that no one got back to you about this. I'm afraid
> that I don't
> > know the answer to your question, I've copied the dev list
> into this
> > email in case someone who monitors that list (but not this one) has
> > any ideas.
> >
> > Best regards,
> >
> > Tom
> >
> > On Thu, Jan 12, 2012 at 2:29 PM, Bryan Thompson
> <br...@systap.com> wrote:
> >> Just to follow up on this thread myself. I modified the
> pattern to return a "thick" future rather than a proxy for
> the future. This caused the RMI call to wait on the server
> until the future was done and then sent back the outcome.
> This "fixed" the DGC memory/thread leak by reducing the
> number of exported proxies drammatically.
> >>
> >> In terms of best practices, is distributed DGC simply not
> useful for exported objects with short life spans? Can it
> only be used with proxies for relatively long lived services?
> >>
> >> Thanks,
> >> Bryan
> >>
> >>> -----Original Message-----
> >>> From: Bryan Thompson
> >>> Sent: Tuesday, January 03, 2012 12:06 PM
> >>> To: user@river.apache.org
> >>> Subject: DGC threads issue
> >>>
> >>> Hello,
> >>>
> >>> Background:
> >>>
> >>> I am seeing what would appear to be one DGC thread allocated per
> >>> exported object. This is using River 2.2 and Sun JDK 1.6.0_17.
> >>> Relevant configuration parameters are below.
> >>>
> >>> I am observing problems with the DGC threads not being
> retired on a
> >>> timely basis. The exported objects are proxies for Futures which
> >>> are being executed on the service. The code pattern is such that
> >>> the proxied Future goes out of lexical scope quite
> quickly. E.g.,
> >>> rmiCallReturningProxyForFuture().get().
> >>>
> >>> Under a modest load, a large number of such Futures are exported
> >>> which results in a large number of long lived DGC threads. This
> >>> turns into a problem for the JVM due to the stack allocation per
> >>> thread. Presumably this is not good for other reasons as well
> >>> (e.g., scheduling).
> >>>
> >>> I have tried to override the leaseValue and checkInterval
> defaults
> >>> per the configuration options below. I suspect that the lease
> >>> interval is somehow not being obeyed, which is presumably
> a problem
> >>> on my end. However, I can verify that the configuration
> values are
> >>> in fact showing up in
> >>> System.getProperties() for at least some of the JVMs
> involved (the
> >>> one which drives the workload and the one that I am
> monitoring with
> >>> the large number of DGC lease threads).
> >>>
> >>> Some questions:
> >>>
> >>> Is this one-thread-per-exported proxy the expected
> behavior when DGC
> >>> is requested for the exported object?
> >>>
> >>> The DGC lease checker threads appear to expire ~14 - 15 minutes
> >>> after I terminate the process which was originating the RMI
> >>> requests. This is close the sum of the default
> leaseValue (10m) and
> >>> checkInterval (5m) parameters, but maybe there is some
> other timeout
> >>> which is controlling this? If this is the sum of those
> parameters,
> >>> why would the DGC lease threads live until the sum of
> those values?
> >>> I thought that the lease would expire after the leaseValue (10m
> >>> default).
> >>>
> >>> Can the issue I am observing be caused by a low heap
> pressure on the
> >>> JVM to which the RMI proxies were exported? If it fails
> to GC those
> >>> proxies, even though they are reachable, could that cause DGC to
> >>> continue to retain those proxies on the JVM which exported them?
> >>>
> >>> Is there any way to configure DGC to use a thread pool or to have
> >>> the leases managed by a single thread?
> >>>
> >>> Is it possible that there is an interaction with the
> useNIO option?
> >>>
> >>> Relevant options that I am using include:
> >>>
> >>> -Dcom.sun.jini.jeri.tcp.useNIO=true
> >>> -Djava.rmi.dgc.leaseValue=30000
> >>> -Dsun.rmi.dgc.checkInterval=15000
> >>> -Dsun.rmi.transport.tcp.connectionPool=true
> >>>
> >>> Thanks in advance,
> >>> Bryan
>
>
RE: DGC threads issue
Posted by Bryan Thompson <br...@systap.com>.
Peter,
The DGC Threads are in the server JVM. They are nearly all for the exported Futures.
Thanks,
Bryan
> -----Original Message-----
> From: Peter Jones [mailto:pcj@roundroom.net]
> Sent: Friday, January 13, 2012 12:04 AM
> To: user@river.apache.org
> Cc: dev@river.apache.org
> Subject: Re: DGC threads issue
>
> Bryan,
>
> DGC threads should not be per exported object. Generally
> speaking, they tend to be per endpoint (at which there are
> one or more remote objects exported). Are you using any sort
> of custom endpoint implementation? Problems like this can
> occur when an endpoint implementation doesn't implement
> Object.equals and hashCode appropriately, so the expected
> batching of threads (and communication) per endpoint does not occur.
>
> It might help to see, from a thread dump, exactly which DGC
> threads are causing this problem. And they are in the server
> JVM (with all the exported remote objects), not the remote
> callers' JVM(s)?
>
> -- Peter
>
>
> On Jan 12, 2012, at 3:45 PM, Tom Hobbs wrote:
>
> > Hi Bryan,
> >
> > Sorry that no one got back to you about this. I'm afraid
> that I don't
> > know the answer to your question, I've copied the dev list
> into this
> > email in case someone who monitors that list (but not this one) has
> > any ideas.
> >
> > Best regards,
> >
> > Tom
> >
> > On Thu, Jan 12, 2012 at 2:29 PM, Bryan Thompson
> <br...@systap.com> wrote:
> >> Just to follow up on this thread myself. I modified the
> pattern to return a "thick" future rather than a proxy for
> the future. This caused the RMI call to wait on the server
> until the future was done and then sent back the outcome.
> This "fixed" the DGC memory/thread leak by reducing the
> number of exported proxies drammatically.
> >>
> >> In terms of best practices, is distributed DGC simply not
> useful for exported objects with short life spans? Can it
> only be used with proxies for relatively long lived services?
> >>
> >> Thanks,
> >> Bryan
> >>
> >>> -----Original Message-----
> >>> From: Bryan Thompson
> >>> Sent: Tuesday, January 03, 2012 12:06 PM
> >>> To: user@river.apache.org
> >>> Subject: DGC threads issue
> >>>
> >>> Hello,
> >>>
> >>> Background:
> >>>
> >>> I am seeing what would appear to be one DGC thread allocated per
> >>> exported object. This is using River 2.2 and Sun JDK 1.6.0_17.
> >>> Relevant configuration parameters are below.
> >>>
> >>> I am observing problems with the DGC threads not being
> retired on a
> >>> timely basis. The exported objects are proxies for Futures which
> >>> are being executed on the service. The code pattern is such that
> >>> the proxied Future goes out of lexical scope quite
> quickly. E.g.,
> >>> rmiCallReturningProxyForFuture().get().
> >>>
> >>> Under a modest load, a large number of such Futures are exported
> >>> which results in a large number of long lived DGC threads. This
> >>> turns into a problem for the JVM due to the stack allocation per
> >>> thread. Presumably this is not good for other reasons as well
> >>> (e.g., scheduling).
> >>>
> >>> I have tried to override the leaseValue and checkInterval
> defaults
> >>> per the configuration options below. I suspect that the lease
> >>> interval is somehow not being obeyed, which is presumably
> a problem
> >>> on my end. However, I can verify that the configuration
> values are
> >>> in fact showing up in
> >>> System.getProperties() for at least some of the JVMs
> involved (the
> >>> one which drives the workload and the one that I am
> monitoring with
> >>> the large number of DGC lease threads).
> >>>
> >>> Some questions:
> >>>
> >>> Is this one-thread-per-exported proxy the expected
> behavior when DGC
> >>> is requested for the exported object?
> >>>
> >>> The DGC lease checker threads appear to expire ~14 - 15 minutes
> >>> after I terminate the process which was originating the RMI
> >>> requests. This is close the sum of the default
> leaseValue (10m) and
> >>> checkInterval (5m) parameters, but maybe there is some
> other timeout
> >>> which is controlling this? If this is the sum of those
> parameters,
> >>> why would the DGC lease threads live until the sum of
> those values?
> >>> I thought that the lease would expire after the leaseValue (10m
> >>> default).
> >>>
> >>> Can the issue I am observing be caused by a low heap
> pressure on the
> >>> JVM to which the RMI proxies were exported? If it fails
> to GC those
> >>> proxies, even though they are reachable, could that cause DGC to
> >>> continue to retain those proxies on the JVM which exported them?
> >>>
> >>> Is there any way to configure DGC to use a thread pool or to have
> >>> the leases managed by a single thread?
> >>>
> >>> Is it possible that there is an interaction with the
> useNIO option?
> >>>
> >>> Relevant options that I am using include:
> >>>
> >>> -Dcom.sun.jini.jeri.tcp.useNIO=true
> >>> -Djava.rmi.dgc.leaseValue=30000
> >>> -Dsun.rmi.dgc.checkInterval=15000
> >>> -Dsun.rmi.transport.tcp.connectionPool=true
> >>>
> >>> Thanks in advance,
> >>> Bryan
>
>
Re: DGC threads issue
Posted by Peter Jones <pc...@roundroom.net>.
Bryan,
DGC threads should not be per exported object. Generally speaking, they tend to be per endpoint (at which there are one or more remote objects exported). Are you using any sort of custom endpoint implementation? Problems like this can occur when an endpoint implementation doesn't implement Object.equals and hashCode appropriately, so the expected batching of threads (and communication) per endpoint does not occur.
It might help to see, from a thread dump, exactly which DGC threads are causing this problem. And they are in the server JVM (with all the exported remote objects), not the remote callers' JVM(s)?
-- Peter
On Jan 12, 2012, at 3:45 PM, Tom Hobbs wrote:
> Hi Bryan,
>
> Sorry that no one got back to you about this. I'm afraid that I don't
> know the answer to your question, I've copied the dev list into this
> email in case someone who monitors that list (but not this one) has
> any ideas.
>
> Best regards,
>
> Tom
>
> On Thu, Jan 12, 2012 at 2:29 PM, Bryan Thompson <br...@systap.com> wrote:
>> Just to follow up on this thread myself. I modified the pattern to return a "thick" future rather than a proxy for the future. This caused the RMI call to wait on the server until the future was done and then sent back the outcome. This "fixed" the DGC memory/thread leak by reducing the number of exported proxies drammatically.
>>
>> In terms of best practices, is distributed DGC simply not useful for exported objects with short life spans? Can it only be used with proxies for relatively long lived services?
>>
>> Thanks,
>> Bryan
>>
>>> -----Original Message-----
>>> From: Bryan Thompson
>>> Sent: Tuesday, January 03, 2012 12:06 PM
>>> To: user@river.apache.org
>>> Subject: DGC threads issue
>>>
>>> Hello,
>>>
>>> Background:
>>>
>>> I am seeing what would appear to be one DGC thread allocated
>>> per exported object. This is using River 2.2 and Sun JDK
>>> 1.6.0_17. Relevant configuration parameters are below.
>>>
>>> I am observing problems with the DGC threads not being
>>> retired on a timely basis. The exported objects are proxies
>>> for Futures which are being executed on the service. The
>>> code pattern is such that the proxied Future goes out of
>>> lexical scope quite quickly. E.g.,
>>> rmiCallReturningProxyForFuture().get().
>>>
>>> Under a modest load, a large number of such Futures are
>>> exported which results in a large number of long lived DGC
>>> threads. This turns into a problem for the JVM due to the
>>> stack allocation per thread. Presumably this is not good for
>>> other reasons as well (e.g., scheduling).
>>>
>>> I have tried to override the leaseValue and checkInterval
>>> defaults per the configuration options below. I suspect that
>>> the lease interval is somehow not being obeyed, which is
>>> presumably a problem on my end. However, I can verify that
>>> the configuration values are in fact showing up in
>>> System.getProperties() for at least some of the JVMs involved
>>> (the one which drives the workload and the one that I am
>>> monitoring with the large number of DGC lease threads).
>>>
>>> Some questions:
>>>
>>> Is this one-thread-per-exported proxy the expected behavior
>>> when DGC is requested for the exported object?
>>>
>>> The DGC lease checker threads appear to expire ~14 - 15
>>> minutes after I terminate the process which was originating
>>> the RMI requests. This is close the sum of the default
>>> leaseValue (10m) and checkInterval (5m) parameters, but maybe
>>> there is some other timeout which is controlling this? If
>>> this is the sum of those parameters, why would the DGC lease
>>> threads live until the sum of those values? I thought that
>>> the lease would expire after the leaseValue (10m default).
>>>
>>> Can the issue I am observing be caused by a low heap pressure
>>> on the JVM to which the RMI proxies were exported? If it
>>> fails to GC those proxies, even though they are reachable,
>>> could that cause DGC to continue to retain those proxies on
>>> the JVM which exported them?
>>>
>>> Is there any way to configure DGC to use a thread pool or to
>>> have the leases managed by a single thread?
>>>
>>> Is it possible that there is an interaction with the useNIO option?
>>>
>>> Relevant options that I am using include:
>>>
>>> -Dcom.sun.jini.jeri.tcp.useNIO=true
>>> -Djava.rmi.dgc.leaseValue=30000
>>> -Dsun.rmi.dgc.checkInterval=15000
>>> -Dsun.rmi.transport.tcp.connectionPool=true
>>>
>>> Thanks in advance,
>>> Bryan
Re: DGC threads issue
Posted by Peter Jones <pc...@roundroom.net>.
Bryan,
DGC threads should not be per exported object. Generally speaking, they tend to be per endpoint (at which there are one or more remote objects exported). Are you using any sort of custom endpoint implementation? Problems like this can occur when an endpoint implementation doesn't implement Object.equals and hashCode appropriately, so the expected batching of threads (and communication) per endpoint does not occur.
It might help to see, from a thread dump, exactly which DGC threads are causing this problem. And they are in the server JVM (with all the exported remote objects), not the remote callers' JVM(s)?
-- Peter
On Jan 12, 2012, at 3:45 PM, Tom Hobbs wrote:
> Hi Bryan,
>
> Sorry that no one got back to you about this. I'm afraid that I don't
> know the answer to your question, I've copied the dev list into this
> email in case someone who monitors that list (but not this one) has
> any ideas.
>
> Best regards,
>
> Tom
>
> On Thu, Jan 12, 2012 at 2:29 PM, Bryan Thompson <br...@systap.com> wrote:
>> Just to follow up on this thread myself. I modified the pattern to return a "thick" future rather than a proxy for the future. This caused the RMI call to wait on the server until the future was done and then sent back the outcome. This "fixed" the DGC memory/thread leak by reducing the number of exported proxies drammatically.
>>
>> In terms of best practices, is distributed DGC simply not useful for exported objects with short life spans? Can it only be used with proxies for relatively long lived services?
>>
>> Thanks,
>> Bryan
>>
>>> -----Original Message-----
>>> From: Bryan Thompson
>>> Sent: Tuesday, January 03, 2012 12:06 PM
>>> To: user@river.apache.org
>>> Subject: DGC threads issue
>>>
>>> Hello,
>>>
>>> Background:
>>>
>>> I am seeing what would appear to be one DGC thread allocated
>>> per exported object. This is using River 2.2 and Sun JDK
>>> 1.6.0_17. Relevant configuration parameters are below.
>>>
>>> I am observing problems with the DGC threads not being
>>> retired on a timely basis. The exported objects are proxies
>>> for Futures which are being executed on the service. The
>>> code pattern is such that the proxied Future goes out of
>>> lexical scope quite quickly. E.g.,
>>> rmiCallReturningProxyForFuture().get().
>>>
>>> Under a modest load, a large number of such Futures are
>>> exported which results in a large number of long lived DGC
>>> threads. This turns into a problem for the JVM due to the
>>> stack allocation per thread. Presumably this is not good for
>>> other reasons as well (e.g., scheduling).
>>>
>>> I have tried to override the leaseValue and checkInterval
>>> defaults per the configuration options below. I suspect that
>>> the lease interval is somehow not being obeyed, which is
>>> presumably a problem on my end. However, I can verify that
>>> the configuration values are in fact showing up in
>>> System.getProperties() for at least some of the JVMs involved
>>> (the one which drives the workload and the one that I am
>>> monitoring with the large number of DGC lease threads).
>>>
>>> Some questions:
>>>
>>> Is this one-thread-per-exported proxy the expected behavior
>>> when DGC is requested for the exported object?
>>>
>>> The DGC lease checker threads appear to expire ~14 - 15
>>> minutes after I terminate the process which was originating
>>> the RMI requests. This is close the sum of the default
>>> leaseValue (10m) and checkInterval (5m) parameters, but maybe
>>> there is some other timeout which is controlling this? If
>>> this is the sum of those parameters, why would the DGC lease
>>> threads live until the sum of those values? I thought that
>>> the lease would expire after the leaseValue (10m default).
>>>
>>> Can the issue I am observing be caused by a low heap pressure
>>> on the JVM to which the RMI proxies were exported? If it
>>> fails to GC those proxies, even though they are reachable,
>>> could that cause DGC to continue to retain those proxies on
>>> the JVM which exported them?
>>>
>>> Is there any way to configure DGC to use a thread pool or to
>>> have the leases managed by a single thread?
>>>
>>> Is it possible that there is an interaction with the useNIO option?
>>>
>>> Relevant options that I am using include:
>>>
>>> -Dcom.sun.jini.jeri.tcp.useNIO=true
>>> -Djava.rmi.dgc.leaseValue=30000
>>> -Dsun.rmi.dgc.checkInterval=15000
>>> -Dsun.rmi.transport.tcp.connectionPool=true
>>>
>>> Thanks in advance,
>>> Bryan
Re: DGC threads issue
Posted by Tom Hobbs <tv...@googlemail.com>.
Hi Bryan,
Sorry that no one got back to you about this. I'm afraid that I don't
know the answer to your question, I've copied the dev list into this
email in case someone who monitors that list (but not this one) has
any ideas.
Best regards,
Tom
On Thu, Jan 12, 2012 at 2:29 PM, Bryan Thompson <br...@systap.com> wrote:
> Just to follow up on this thread myself. I modified the pattern to return a "thick" future rather than a proxy for the future. This caused the RMI call to wait on the server until the future was done and then sent back the outcome. This "fixed" the DGC memory/thread leak by reducing the number of exported proxies drammatically.
>
> In terms of best practices, is distributed DGC simply not useful for exported objects with short life spans? Can it only be used with proxies for relatively long lived services?
>
> Thanks,
> Bryan
>
>> -----Original Message-----
>> From: Bryan Thompson
>> Sent: Tuesday, January 03, 2012 12:06 PM
>> To: user@river.apache.org
>> Subject: DGC threads issue
>>
>> Hello,
>>
>> Background:
>>
>> I am seeing what would appear to be one DGC thread allocated
>> per exported object. This is using River 2.2 and Sun JDK
>> 1.6.0_17. Relevant configuration parameters are below.
>>
>> I am observing problems with the DGC threads not being
>> retired on a timely basis. The exported objects are proxies
>> for Futures which are being executed on the service. The
>> code pattern is such that the proxied Future goes out of
>> lexical scope quite quickly. E.g.,
>> rmiCallReturningProxyForFuture().get().
>>
>> Under a modest load, a large number of such Futures are
>> exported which results in a large number of long lived DGC
>> threads. This turns into a problem for the JVM due to the
>> stack allocation per thread. Presumably this is not good for
>> other reasons as well (e.g., scheduling).
>>
>> I have tried to override the leaseValue and checkInterval
>> defaults per the configuration options below. I suspect that
>> the lease interval is somehow not being obeyed, which is
>> presumably a problem on my end. However, I can verify that
>> the configuration values are in fact showing up in
>> System.getProperties() for at least some of the JVMs involved
>> (the one which drives the workload and the one that I am
>> monitoring with the large number of DGC lease threads).
>>
>> Some questions:
>>
>> Is this one-thread-per-exported proxy the expected behavior
>> when DGC is requested for the exported object?
>>
>> The DGC lease checker threads appear to expire ~14 - 15
>> minutes after I terminate the process which was originating
>> the RMI requests. This is close the sum of the default
>> leaseValue (10m) and checkInterval (5m) parameters, but maybe
>> there is some other timeout which is controlling this? If
>> this is the sum of those parameters, why would the DGC lease
>> threads live until the sum of those values? I thought that
>> the lease would expire after the leaseValue (10m default).
>>
>> Can the issue I am observing be caused by a low heap pressure
>> on the JVM to which the RMI proxies were exported? If it
>> fails to GC those proxies, even though they are reachable,
>> could that cause DGC to continue to retain those proxies on
>> the JVM which exported them?
>>
>> Is there any way to configure DGC to use a thread pool or to
>> have the leases managed by a single thread?
>>
>> Is it possible that there is an interaction with the useNIO option?
>>
>> Relevant options that I am using include:
>>
>> -Dcom.sun.jini.jeri.tcp.useNIO=true
>> -Djava.rmi.dgc.leaseValue=30000
>> -Dsun.rmi.dgc.checkInterval=15000
>> -Dsun.rmi.transport.tcp.connectionPool=true
>>
>> Thanks in advance,
>> Bryan
Re: DGC threads issue
Posted by Tom Hobbs <tv...@googlemail.com>.
Hi Bryan,
Sorry that no one got back to you about this. I'm afraid that I don't
know the answer to your question, I've copied the dev list into this
email in case someone who monitors that list (but not this one) has
any ideas.
Best regards,
Tom
On Thu, Jan 12, 2012 at 2:29 PM, Bryan Thompson <br...@systap.com> wrote:
> Just to follow up on this thread myself. I modified the pattern to return a "thick" future rather than a proxy for the future. This caused the RMI call to wait on the server until the future was done and then sent back the outcome. This "fixed" the DGC memory/thread leak by reducing the number of exported proxies drammatically.
>
> In terms of best practices, is distributed DGC simply not useful for exported objects with short life spans? Can it only be used with proxies for relatively long lived services?
>
> Thanks,
> Bryan
>
>> -----Original Message-----
>> From: Bryan Thompson
>> Sent: Tuesday, January 03, 2012 12:06 PM
>> To: user@river.apache.org
>> Subject: DGC threads issue
>>
>> Hello,
>>
>> Background:
>>
>> I am seeing what would appear to be one DGC thread allocated
>> per exported object. This is using River 2.2 and Sun JDK
>> 1.6.0_17. Relevant configuration parameters are below.
>>
>> I am observing problems with the DGC threads not being
>> retired on a timely basis. The exported objects are proxies
>> for Futures which are being executed on the service. The
>> code pattern is such that the proxied Future goes out of
>> lexical scope quite quickly. E.g.,
>> rmiCallReturningProxyForFuture().get().
>>
>> Under a modest load, a large number of such Futures are
>> exported which results in a large number of long lived DGC
>> threads. This turns into a problem for the JVM due to the
>> stack allocation per thread. Presumably this is not good for
>> other reasons as well (e.g., scheduling).
>>
>> I have tried to override the leaseValue and checkInterval
>> defaults per the configuration options below. I suspect that
>> the lease interval is somehow not being obeyed, which is
>> presumably a problem on my end. However, I can verify that
>> the configuration values are in fact showing up in
>> System.getProperties() for at least some of the JVMs involved
>> (the one which drives the workload and the one that I am
>> monitoring with the large number of DGC lease threads).
>>
>> Some questions:
>>
>> Is this one-thread-per-exported proxy the expected behavior
>> when DGC is requested for the exported object?
>>
>> The DGC lease checker threads appear to expire ~14 - 15
>> minutes after I terminate the process which was originating
>> the RMI requests. This is close the sum of the default
>> leaseValue (10m) and checkInterval (5m) parameters, but maybe
>> there is some other timeout which is controlling this? If
>> this is the sum of those parameters, why would the DGC lease
>> threads live until the sum of those values? I thought that
>> the lease would expire after the leaseValue (10m default).
>>
>> Can the issue I am observing be caused by a low heap pressure
>> on the JVM to which the RMI proxies were exported? If it
>> fails to GC those proxies, even though they are reachable,
>> could that cause DGC to continue to retain those proxies on
>> the JVM which exported them?
>>
>> Is there any way to configure DGC to use a thread pool or to
>> have the leases managed by a single thread?
>>
>> Is it possible that there is an interaction with the useNIO option?
>>
>> Relevant options that I am using include:
>>
>> -Dcom.sun.jini.jeri.tcp.useNIO=true
>> -Djava.rmi.dgc.leaseValue=30000
>> -Dsun.rmi.dgc.checkInterval=15000
>> -Dsun.rmi.transport.tcp.connectionPool=true
>>
>> Thanks in advance,
>> Bryan
RE: DGC threads issue
Posted by Bryan Thompson <br...@systap.com>.
Just to follow up on this thread myself. I modified the pattern to return a "thick" future rather than a proxy for the future. This caused the RMI call to wait on the server until the future was done and then sent back the outcome. This "fixed" the DGC memory/thread leak by reducing the number of exported proxies drammatically.
In terms of best practices, is distributed DGC simply not useful for exported objects with short life spans? Can it only be used with proxies for relatively long lived services?
Thanks,
Bryan
> -----Original Message-----
> From: Bryan Thompson
> Sent: Tuesday, January 03, 2012 12:06 PM
> To: user@river.apache.org
> Subject: DGC threads issue
>
> Hello,
>
> Background:
>
> I am seeing what would appear to be one DGC thread allocated
> per exported object. This is using River 2.2 and Sun JDK
> 1.6.0_17. Relevant configuration parameters are below.
>
> I am observing problems with the DGC threads not being
> retired on a timely basis. The exported objects are proxies
> for Futures which are being executed on the service. The
> code pattern is such that the proxied Future goes out of
> lexical scope quite quickly. E.g.,
> rmiCallReturningProxyForFuture().get().
>
> Under a modest load, a large number of such Futures are
> exported which results in a large number of long lived DGC
> threads. This turns into a problem for the JVM due to the
> stack allocation per thread. Presumably this is not good for
> other reasons as well (e.g., scheduling).
>
> I have tried to override the leaseValue and checkInterval
> defaults per the configuration options below. I suspect that
> the lease interval is somehow not being obeyed, which is
> presumably a problem on my end. However, I can verify that
> the configuration values are in fact showing up in
> System.getProperties() for at least some of the JVMs involved
> (the one which drives the workload and the one that I am
> monitoring with the large number of DGC lease threads).
>
> Some questions:
>
> Is this one-thread-per-exported proxy the expected behavior
> when DGC is requested for the exported object?
>
> The DGC lease checker threads appear to expire ~14 - 15
> minutes after I terminate the process which was originating
> the RMI requests. This is close the sum of the default
> leaseValue (10m) and checkInterval (5m) parameters, but maybe
> there is some other timeout which is controlling this? If
> this is the sum of those parameters, why would the DGC lease
> threads live until the sum of those values? I thought that
> the lease would expire after the leaseValue (10m default).
>
> Can the issue I am observing be caused by a low heap pressure
> on the JVM to which the RMI proxies were exported? If it
> fails to GC those proxies, even though they are reachable,
> could that cause DGC to continue to retain those proxies on
> the JVM which exported them?
>
> Is there any way to configure DGC to use a thread pool or to
> have the leases managed by a single thread?
>
> Is it possible that there is an interaction with the useNIO option?
>
> Relevant options that I am using include:
>
> -Dcom.sun.jini.jeri.tcp.useNIO=true
> -Djava.rmi.dgc.leaseValue=30000
> -Dsun.rmi.dgc.checkInterval=15000
> -Dsun.rmi.transport.tcp.connectionPool=true
>
> Thanks in advance,
> Bryan
DGC threads issue
Posted by Bryan Thompson <br...@systap.com>.
Hello,
Background:
I am seeing what would appear to be one DGC thread allocated per exported object. This is using River 2.2 and Sun JDK 1.6.0_17. Relevant configuration parameters are below.
I am observing problems with the DGC threads not being retired on a timely basis. The exported objects are proxies for Futures which are being executed on the service. The code pattern is such that the proxied Future goes out of lexical scope quite quickly. E.g., rmiCallReturningProxyForFuture().get().
Under a modest load, a large number of such Futures are exported which results in a large number of long lived DGC threads. This turns into a problem for the JVM due to the stack allocation per thread. Presumably this is not good for other reasons as well (e.g., scheduling).
I have tried to override the leaseValue and checkInterval defaults per the configuration options below. I suspect that the lease interval is somehow not being obeyed, which is presumably a problem on my end. However, I can verify that the configuration values are in fact showing up in System.getProperties() for at least some of the JVMs involved (the one which drives the workload and the one that I am monitoring with the large number of DGC lease threads).
Some questions:
Is this one-thread-per-exported proxy the expected behavior when DGC is requested for the exported object?
The DGC lease checker threads appear to expire ~14 - 15 minutes after I terminate the process which was originating the RMI requests. This is close the sum of the default leaseValue (10m) and checkInterval (5m) parameters, but maybe there is some other timeout which is controlling this? If this is the sum of those parameters, why would the DGC lease threads live until the sum of those values? I thought that the lease would expire after the leaseValue (10m default).
Can the issue I am observing be caused by a low heap pressure on the JVM to which the RMI proxies were exported? If it fails to GC those proxies, even though they are reachable, could that cause DGC to continue to retain those proxies on the JVM which exported them?
Is there any way to configure DGC to use a thread pool or to have the leases managed by a single thread?
Is it possible that there is an interaction with the useNIO option?
Relevant options that I am using include:
-Dcom.sun.jini.jeri.tcp.useNIO=true
-Djava.rmi.dgc.leaseValue=30000
-Dsun.rmi.dgc.checkInterval=15000
-Dsun.rmi.transport.tcp.connectionPool=true
Thanks in advance,
Bryan
Re: what should be written in a config file for service application?
Posted by Gregg Wonderly <ge...@cox.net>.
One of the reasons why I created my PersistentJiniService class in the
startnow.dev.java.net project was to facilitate this style of learning. I found
it was convenient for me to have all of the "code" already done so that services
could be started "easily", and then there was code, in one place, that I could
go back to, and stare at, to see how that part of Jini worked.
The simple service is something like
public class MyService extends PersistentJiniService implements MyInterface {
public static void main( String args[] ) {
new MyService( args, null );
}
public MyService( String[]args, LifeCycle life ) {
super( args );
startService( "myServiceName", "myPersistentStore" );
}
}
I'm not really that excited by the state of that old code any more, but I'd
really like to find some time to clean it up, and then put something like this
into River so that the "command line" and the "com.sun.jini.start" paths are
both covered and ready for people to be able to use for deployment.
Sometime back, I asked about trying to create an "interface" that we could use
for all of the "containers" that exist, so that we'd be able to create something
like this that would provide for portability between the containers.
Gregg Wonderly
On 12/16/2011 11:19 AM, Dan Creswell wrote:
> Inline...
>
> On 16 December 2011 13:48, Ashutosh Singh<dh...@hotmail.com> wrote:
>>
>> I am sorry for the getting the numbers fumbled up.
>>
>
> That's okay, it just slows us down in helping you, ultimately we'll
> get the right answer.
>
>> I was talking about
>>
>> public JoinManager(Object serviceProxy,
>> Entry[] attrSets,
>> ServiceIDListener callback,
>> DiscoveryManagement discoveryMgr,
>> LeaseRenewalManager leaseMgr)
>> throws IOException
>>
>> For the config file I was talking about other constructors that contain last argument as Configuration object.
>> I am again sorry for not being precise.
>>
>>
>> Now, as from the specs I think Entry[] attributes means the attributes that are used to process, manage and identify a
>> service as there can be many services and these attributes help us to match a minimum of one services.
>>
>> I have created an Entry array using EmptyConfiguration from
>> net.jini.config.EmptyConfiguration as
>>
>> Entry[] myattrs = (Entry[]) EmptyConfiguration.INSTANCE.getEntry("com.siolabs.jini.Server","sioLabs" , Entry[].class);
>>
>> with the help from blog
>> http://www.jroller.com/dancres/entry/how_to_write_a_jini
>>
>
> Oh, I wrote that one :)
>
>>
>> If something above is wrong please correct me .
>>
>
> Nothing wrong as such but you don't need to do this unless you want
> to. It'd be perfectly fine to have:
>
> Entry[] myattrs = new Entry[0];
>
> Or indeed:
>
> Entry[] myattrs = new Entry[] {new ServiceInfo("serviceName",
> "manufacturer", "vendor", "1.0", "model", "serialNumber")};
>
> The only difference is that you can configure exactly what attributes
> you want. Most services end up allowing some configuration but also
> assert some defaults in the code but when getting started, hard-coding
> is fine. Configuration can wait...
>
>> I have written following steps.
>>
>> 1. Writing a Service Interface
>> 2. Writing a Service Implementation Class
>> 2.1 Used BasicJeriExporter
>> 2.2 Created Service Id
>> 2.3 Created a proxy Object for Service
>> 2.4 Finding reggie instances using LookupLocator
>> 2.5 Getting a LookupDiscoveryManager
>> 2.6 Got Entry[] using EmptyConfiguration
>> 2.7 Create a JoinManagerInstance with the constructor I specified above
>>
>>
>>
>>
>> I think that my service is completed now or Is there something left??
>
> On first look I'd say you've got it all done but without a thorough
> review of all your code I can't be certain. There's one thing I did
> notice which I think might need tweaking which is your LookupLocator:
>
> new LookupLocator("jini://localhost:8080")
>
> The default for a lookup service would be port 4160 so unless you've
> configured your lookup service to sit on 8080 you'd want to change
> that locator to either of:
>
> new LookupLocator("jini://localhost")
>
> or:
>
> new LookupLocator("jini://localhost:4160")
>
>> Regards
>> Ashutosh Singh
>> .
>>
>>> Date: Fri, 16 Dec 2011 12:52:57 +0000
>>> Subject: Re: what should be written in a config file for service application?
>>> From: dan.creswell@gmail.com
>>> To: user@river.apache.org
>>>
>>> Inline....
>>>
>>> On 16 December 2011 12:24, Ashutosh Singh<dh...@hotmail.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I am trying to do that. here is my code.
>>>>
>>>> ///////////////////////Service Class/////////////
>>>>
>>>> public class Server implements Hello{
>>>>
>>>> private LookupDiscoveryManager ldm = null;
>>>>
>>>>
>>>> public Server() throws IOException{
>>>> init();
>>>> }
>>>>
>>>>
>>>> @Override
>>>> public String sayHello() {
>>>> // TODO Auto-generated method stub
>>>> return "Hello World";
>>>>
>>>> }
>>>>
>>>> public void init() throws IOException{
>>>> System.out.println("in server main");
>>>> Exporter myExporter = new BasicJeriExporter(TcpServerEndpoint.getInstance(0), new BasicILFactory());
>>>>
>>>> // Create a service id as required by the join Manager
>>>> Uuid myuuid = UuidFactory.generate();
>>>> ServiceID myService = new ServiceID(myuuid.getMostSignificantBits(), myuuid.getLeastSignificantBits());
>>>>
>>>> //Create the object proxy for use by joiinmanager
>>>> Server myProxy = (Server) myExporter.export(this);
>>>>
>>>> //find the reggie instances
>>>> LookupLocator[] myLocator = new LookupLocator[]{new LookupLocator("jini://localhost:8080")};
>>>>
>>>> ldm = new LookupDiscoveryManager(DiscoveryGroupManagement.ALL_GROUPS, myLocator,null );
>>>>
>>>> //Now join them
>>>> }
>>>>
>>>> public static void main(String[] args) throws IOException {
>>>> }
>>>>
>>>> }
>>>>
>>>> /************** *****************/
>>>>
>>>> Now as the Join Manager takes 4 arguments and since I am not using a config file .
>>>
>>> I'm a little confused as the API docs here: http://river.apache.org/doc/api/
>>>
>>> Show no constructor that takes only 4 arguments. Did you really mean
>>> JoinManager?
>>>
>>>> How can I provide entry attr sets . From the documentation I found that
>>>>
>>>> "attrSets - array of Entry consisting of the
>>>> attribute sets with which to register the service"
>>>>
>>>> But with Entry Interface i don't know what to write.
>>>> Please tell what will go in an entry?
>>>>
>>>
>>> You would typically include the "standard" attributes such as:
>>>
>>> net.jini.lookup.entry.ServiceInfo
>>>
>>> More on that is here in the specifications:
>>>
>>> http://river.apache.org/doc/specs/html/schema-spec.html#31204
>>>
>>>> Also can I provide the config argument of JoinManager as null?
>>>
>>> Given the above re: constructors can you please point me at the
>>> constructor you're using? JoinManager has at least one constructor:
>>>
>>> JoinManager(Object serviceProxy, Entry[] attrSets, ServiceID
>>> serviceID, DiscoveryManagement discoveryMgr, LeaseRenewalManager
>>> leaseMgr)
>>>
>>> That doesn't take a configuration file. Perhaps you meant
>>> LookupDiscoveryManager? Again:
>>>
>>> LookupDiscoveryManager(String[] groups, LookupLocator[] locators,
>>> DiscoveryListener listener)
>>>
>>> That has a constructor that doesn't require a configuration file.
>>>
>>>
>>>>
>>>> Regards
>>>> Ashutosh Singh
>>>>
>>>>
>>>>> Date: Thu, 15 Dec 2011 13:00:22 +0000
>>>>> Subject: Re: what should be written in a config file for service application?
>>>>> From: dan.creswell@gmail.com
>>>>> To: user@river.apache.org
>>>>>
>>>>> Okay so then you don't need to put anything in a configuration file.
>>>>> You can hard-code the lot and then come back and do configuration
>>>>> later as it makes sense.
>>>>>
>>>>> Probably the simplest you can go is to use lookuplocators to find the
>>>>> lookup service and register/lookup.
>>>>>
>>>>> On 15 December 2011 12:54, Ashutosh Singh<dh...@hotmail.com> wrote:
>>>>>>
>>>>>> The hello example given contains a complicated server with all the smart proxies and different methods of exporting.
>>>>>>
>>>>>> So I am just writing a very basic Hello World application that uses a jeri protocol. No SDM's!.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Date: Thu, 15 Dec 2011 12:47:58 +0000
>>>>>>> Subject: Re: what should be written in a config file for service application?
>>>>>>> From: dan.creswell@gmail.com
>>>>>>> To: user@river.apache.org
>>>>>>>
>>>>>>> Are you configuring one of the standard services, one of your own or
>>>>>>> one of the examples?
>>>>>>>
>>>>>>> On 15 December 2011 11:36, Ashutosh Singh<dh...@hotmail.com> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I am a novice RIVER user?
>>>>>>>>
>>>>>>>> Can you please tell me what should be written in a config file for a service application?
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Ashutosh Singh
>>>>>>>>
>>>>>>
>>>>
>>
>
Re: what should be written in a config file for service application?
Posted by Dan Creswell <da...@gmail.com>.
Inline...
On 16 December 2011 13:48, Ashutosh Singh <dh...@hotmail.com> wrote:
>
> I am sorry for the getting the numbers fumbled up.
>
That's okay, it just slows us down in helping you, ultimately we'll
get the right answer.
> I was talking about
>
> public JoinManager(Object serviceProxy,
> Entry[] attrSets,
> ServiceIDListener callback,
> DiscoveryManagement discoveryMgr,
> LeaseRenewalManager leaseMgr)
> throws IOException
>
> For the config file I was talking about other constructors that contain last argument as Configuration object.
> I am again sorry for not being precise.
>
>
> Now, as from the specs I think Entry[] attributes means the attributes that are used to process, manage and identify a
> service as there can be many services and these attributes help us to match a minimum of one services.
>
> I have created an Entry array using EmptyConfiguration from
> net.jini.config.EmptyConfiguration as
>
> Entry[] myattrs = (Entry[]) EmptyConfiguration.INSTANCE.getEntry("com.siolabs.jini.Server","sioLabs" , Entry[].class);
>
> with the help from blog
> http://www.jroller.com/dancres/entry/how_to_write_a_jini
>
Oh, I wrote that one :)
>
> If something above is wrong please correct me .
>
Nothing wrong as such but you don't need to do this unless you want
to. It'd be perfectly fine to have:
Entry[] myattrs = new Entry[0];
Or indeed:
Entry[] myattrs = new Entry[] {new ServiceInfo("serviceName",
"manufacturer", "vendor", "1.0", "model", "serialNumber")};
The only difference is that you can configure exactly what attributes
you want. Most services end up allowing some configuration but also
assert some defaults in the code but when getting started, hard-coding
is fine. Configuration can wait...
> I have written following steps.
>
> 1. Writing a Service Interface
> 2. Writing a Service Implementation Class
> 2.1 Used BasicJeriExporter
> 2.2 Created Service Id
> 2.3 Created a proxy Object for Service
> 2.4 Finding reggie instances using LookupLocator
> 2.5 Getting a LookupDiscoveryManager
> 2.6 Got Entry[] using EmptyConfiguration
> 2.7 Create a JoinManagerInstance with the constructor I specified above
>
>
>
>
> I think that my service is completed now or Is there something left??
On first look I'd say you've got it all done but without a thorough
review of all your code I can't be certain. There's one thing I did
notice which I think might need tweaking which is your LookupLocator:
new LookupLocator("jini://localhost:8080")
The default for a lookup service would be port 4160 so unless you've
configured your lookup service to sit on 8080 you'd want to change
that locator to either of:
new LookupLocator("jini://localhost")
or:
new LookupLocator("jini://localhost:4160")
> Regards
> Ashutosh Singh
> .
>
>> Date: Fri, 16 Dec 2011 12:52:57 +0000
>> Subject: Re: what should be written in a config file for service application?
>> From: dan.creswell@gmail.com
>> To: user@river.apache.org
>>
>> Inline....
>>
>> On 16 December 2011 12:24, Ashutosh Singh <dh...@hotmail.com> wrote:
>> >
>> > Hi,
>> >
>> > I am trying to do that. here is my code.
>> >
>> > ///////////////////////Service Class/////////////
>> >
>> > public class Server implements Hello{
>> >
>> > private LookupDiscoveryManager ldm = null;
>> >
>> >
>> > public Server() throws IOException{
>> > init();
>> > }
>> >
>> >
>> > @Override
>> > public String sayHello() {
>> > // TODO Auto-generated method stub
>> > return "Hello World";
>> >
>> > }
>> >
>> > public void init() throws IOException{
>> > System.out.println("in server main");
>> > Exporter myExporter = new BasicJeriExporter(TcpServerEndpoint.getInstance(0), new BasicILFactory());
>> >
>> > // Create a service id as required by the join Manager
>> > Uuid myuuid = UuidFactory.generate();
>> > ServiceID myService = new ServiceID(myuuid.getMostSignificantBits(), myuuid.getLeastSignificantBits());
>> >
>> > //Create the object proxy for use by joiinmanager
>> > Server myProxy = (Server) myExporter.export(this);
>> >
>> > //find the reggie instances
>> > LookupLocator[] myLocator = new LookupLocator[]{new LookupLocator("jini://localhost:8080")};
>> >
>> > ldm = new LookupDiscoveryManager(DiscoveryGroupManagement.ALL_GROUPS, myLocator,null );
>> >
>> > //Now join them
>> > }
>> >
>> > public static void main(String[] args) throws IOException {
>> > }
>> >
>> > }
>> >
>> > /************** *****************/
>> >
>> > Now as the Join Manager takes 4 arguments and since I am not using a config file .
>>
>> I'm a little confused as the API docs here: http://river.apache.org/doc/api/
>>
>> Show no constructor that takes only 4 arguments. Did you really mean
>> JoinManager?
>>
>> > How can I provide entry attr sets . From the documentation I found that
>> >
>> > "attrSets - array of Entry consisting of the
>> > attribute sets with which to register the service"
>> >
>> > But with Entry Interface i don't know what to write.
>> > Please tell what will go in an entry?
>> >
>>
>> You would typically include the "standard" attributes such as:
>>
>> net.jini.lookup.entry.ServiceInfo
>>
>> More on that is here in the specifications:
>>
>> http://river.apache.org/doc/specs/html/schema-spec.html#31204
>>
>> > Also can I provide the config argument of JoinManager as null?
>>
>> Given the above re: constructors can you please point me at the
>> constructor you're using? JoinManager has at least one constructor:
>>
>> JoinManager(Object serviceProxy, Entry[] attrSets, ServiceID
>> serviceID, DiscoveryManagement discoveryMgr, LeaseRenewalManager
>> leaseMgr)
>>
>> That doesn't take a configuration file. Perhaps you meant
>> LookupDiscoveryManager? Again:
>>
>> LookupDiscoveryManager(String[] groups, LookupLocator[] locators,
>> DiscoveryListener listener)
>>
>> That has a constructor that doesn't require a configuration file.
>>
>>
>> >
>> > Regards
>> > Ashutosh Singh
>> >
>> >
>> >> Date: Thu, 15 Dec 2011 13:00:22 +0000
>> >> Subject: Re: what should be written in a config file for service application?
>> >> From: dan.creswell@gmail.com
>> >> To: user@river.apache.org
>> >>
>> >> Okay so then you don't need to put anything in a configuration file.
>> >> You can hard-code the lot and then come back and do configuration
>> >> later as it makes sense.
>> >>
>> >> Probably the simplest you can go is to use lookuplocators to find the
>> >> lookup service and register/lookup.
>> >>
>> >> On 15 December 2011 12:54, Ashutosh Singh <dh...@hotmail.com> wrote:
>> >> >
>> >> > The hello example given contains a complicated server with all the smart proxies and different methods of exporting.
>> >> >
>> >> > So I am just writing a very basic Hello World application that uses a jeri protocol. No SDM's!.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >> Date: Thu, 15 Dec 2011 12:47:58 +0000
>> >> >> Subject: Re: what should be written in a config file for service application?
>> >> >> From: dan.creswell@gmail.com
>> >> >> To: user@river.apache.org
>> >> >>
>> >> >> Are you configuring one of the standard services, one of your own or
>> >> >> one of the examples?
>> >> >>
>> >> >> On 15 December 2011 11:36, Ashutosh Singh <dh...@hotmail.com> wrote:
>> >> >> >
>> >> >> > Hi,
>> >> >> >
>> >> >> > I am a novice RIVER user?
>> >> >> >
>> >> >> > Can you please tell me what should be written in a config file for a service application?
>> >> >> >
>> >> >> > Regards
>> >> >> > Ashutosh Singh
>> >> >> >
>> >> >
>> >
>
RE: what should be written in a config file for service application?
Posted by Ashutosh Singh <dh...@hotmail.com>.
I am sorry for the getting the numbers fumbled up.
I was talking about
public JoinManager(Object serviceProxy,
Entry[] attrSets,
ServiceIDListener callback,
DiscoveryManagement discoveryMgr,
LeaseRenewalManager leaseMgr)
throws IOException
For the config file I was talking about other constructors that contain last argument as Configuration object.
I am again sorry for not being precise.
Now, as from the specs I think Entry[] attributes means the attributes that are used to process, manage and identify a
service as there can be many services and these attributes help us to match a minimum of one services.
I have created an Entry array using EmptyConfiguration from
net.jini.config.EmptyConfiguration as
Entry[] myattrs = (Entry[]) EmptyConfiguration.INSTANCE.getEntry("com.siolabs.jini.Server","sioLabs" , Entry[].class);
with the help from blog
http://www.jroller.com/dancres/entry/how_to_write_a_jini
If something above is wrong please correct me .
I have written following steps.
1. Writing a Service Interface
2. Writing a Service Implementation Class
2.1 Used BasicJeriExporter
2.2 Created Service Id
2.3 Created a proxy Object for Service
2.4 Finding reggie instances using LookupLocator
2.5 Getting a LookupDiscoveryManager
2.6 Got Entry[] using EmptyConfiguration
2.7 Create a JoinManagerInstance with the constructor I specified above
I think that my service is completed now or Is there something left??
Regards
Ashutosh Singh
.
> Date: Fri, 16 Dec 2011 12:52:57 +0000
> Subject: Re: what should be written in a config file for service application?
> From: dan.creswell@gmail.com
> To: user@river.apache.org
>
> Inline....
>
> On 16 December 2011 12:24, Ashutosh Singh <dh...@hotmail.com> wrote:
> >
> > Hi,
> >
> > I am trying to do that. here is my code.
> >
> > ///////////////////////Service Class/////////////
> >
> > public class Server implements Hello{
> >
> > private LookupDiscoveryManager ldm = null;
> >
> >
> > public Server() throws IOException{
> > init();
> > }
> >
> >
> > @Override
> > public String sayHello() {
> > // TODO Auto-generated method stub
> > return "Hello World";
> >
> > }
> >
> > public void init() throws IOException{
> > System.out.println("in server main");
> > Exporter myExporter = new BasicJeriExporter(TcpServerEndpoint.getInstance(0), new BasicILFactory());
> >
> > // Create a service id as required by the join Manager
> > Uuid myuuid = UuidFactory.generate();
> > ServiceID myService = new ServiceID(myuuid.getMostSignificantBits(), myuuid.getLeastSignificantBits());
> >
> > //Create the object proxy for use by joiinmanager
> > Server myProxy = (Server) myExporter.export(this);
> >
> > //find the reggie instances
> > LookupLocator[] myLocator = new LookupLocator[]{new LookupLocator("jini://localhost:8080")};
> >
> > ldm = new LookupDiscoveryManager(DiscoveryGroupManagement.ALL_GROUPS, myLocator,null );
> >
> > //Now join them
> > }
> >
> > public static void main(String[] args) throws IOException {
> > }
> >
> > }
> >
> > /************** *****************/
> >
> > Now as the Join Manager takes 4 arguments and since I am not using a config file .
>
> I'm a little confused as the API docs here: http://river.apache.org/doc/api/
>
> Show no constructor that takes only 4 arguments. Did you really mean
> JoinManager?
>
> > How can I provide entry attr sets . From the documentation I found that
> >
> > "attrSets - array of Entry consisting of the
> > attribute sets with which to register the service"
> >
> > But with Entry Interface i don't know what to write.
> > Please tell what will go in an entry?
> >
>
> You would typically include the "standard" attributes such as:
>
> net.jini.lookup.entry.ServiceInfo
>
> More on that is here in the specifications:
>
> http://river.apache.org/doc/specs/html/schema-spec.html#31204
>
> > Also can I provide the config argument of JoinManager as null?
>
> Given the above re: constructors can you please point me at the
> constructor you're using? JoinManager has at least one constructor:
>
> JoinManager(Object serviceProxy, Entry[] attrSets, ServiceID
> serviceID, DiscoveryManagement discoveryMgr, LeaseRenewalManager
> leaseMgr)
>
> That doesn't take a configuration file. Perhaps you meant
> LookupDiscoveryManager? Again:
>
> LookupDiscoveryManager(String[] groups, LookupLocator[] locators,
> DiscoveryListener listener)
>
> That has a constructor that doesn't require a configuration file.
>
>
> >
> > Regards
> > Ashutosh Singh
> >
> >
> >> Date: Thu, 15 Dec 2011 13:00:22 +0000
> >> Subject: Re: what should be written in a config file for service application?
> >> From: dan.creswell@gmail.com
> >> To: user@river.apache.org
> >>
> >> Okay so then you don't need to put anything in a configuration file.
> >> You can hard-code the lot and then come back and do configuration
> >> later as it makes sense.
> >>
> >> Probably the simplest you can go is to use lookuplocators to find the
> >> lookup service and register/lookup.
> >>
> >> On 15 December 2011 12:54, Ashutosh Singh <dh...@hotmail.com> wrote:
> >> >
> >> > The hello example given contains a complicated server with all the smart proxies and different methods of exporting.
> >> >
> >> > So I am just writing a very basic Hello World application that uses a jeri protocol. No SDM's!.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >> Date: Thu, 15 Dec 2011 12:47:58 +0000
> >> >> Subject: Re: what should be written in a config file for service application?
> >> >> From: dan.creswell@gmail.com
> >> >> To: user@river.apache.org
> >> >>
> >> >> Are you configuring one of the standard services, one of your own or
> >> >> one of the examples?
> >> >>
> >> >> On 15 December 2011 11:36, Ashutosh Singh <dh...@hotmail.com> wrote:
> >> >> >
> >> >> > Hi,
> >> >> >
> >> >> > I am a novice RIVER user?
> >> >> >
> >> >> > Can you please tell me what should be written in a config file for a service application?
> >> >> >
> >> >> > Regards
> >> >> > Ashutosh Singh
> >> >> >
> >> >
> >
Re: what should be written in a config file for service application?
Posted by Dan Creswell <da...@gmail.com>.
Inline....
On 16 December 2011 12:24, Ashutosh Singh <dh...@hotmail.com> wrote:
>
> Hi,
>
> I am trying to do that. here is my code.
>
> ///////////////////////Service Class/////////////
>
> public class Server implements Hello{
>
> private LookupDiscoveryManager ldm = null;
>
>
> public Server() throws IOException{
> init();
> }
>
>
> @Override
> public String sayHello() {
> // TODO Auto-generated method stub
> return "Hello World";
>
> }
>
> public void init() throws IOException{
> System.out.println("in server main");
> Exporter myExporter = new BasicJeriExporter(TcpServerEndpoint.getInstance(0), new BasicILFactory());
>
> // Create a service id as required by the join Manager
> Uuid myuuid = UuidFactory.generate();
> ServiceID myService = new ServiceID(myuuid.getMostSignificantBits(), myuuid.getLeastSignificantBits());
>
> //Create the object proxy for use by joiinmanager
> Server myProxy = (Server) myExporter.export(this);
>
> //find the reggie instances
> LookupLocator[] myLocator = new LookupLocator[]{new LookupLocator("jini://localhost:8080")};
>
> ldm = new LookupDiscoveryManager(DiscoveryGroupManagement.ALL_GROUPS, myLocator,null );
>
> //Now join them
> }
>
> public static void main(String[] args) throws IOException {
> }
>
> }
>
> /************** *****************/
>
> Now as the Join Manager takes 4 arguments and since I am not using a config file .
I'm a little confused as the API docs here: http://river.apache.org/doc/api/
Show no constructor that takes only 4 arguments. Did you really mean
JoinManager?
> How can I provide entry attr sets . From the documentation I found that
>
> "attrSets - array of Entry consisting of the
> attribute sets with which to register the service"
>
> But with Entry Interface i don't know what to write.
> Please tell what will go in an entry?
>
You would typically include the "standard" attributes such as:
net.jini.lookup.entry.ServiceInfo
More on that is here in the specifications:
http://river.apache.org/doc/specs/html/schema-spec.html#31204
> Also can I provide the config argument of JoinManager as null?
Given the above re: constructors can you please point me at the
constructor you're using? JoinManager has at least one constructor:
JoinManager(Object serviceProxy, Entry[] attrSets, ServiceID
serviceID, DiscoveryManagement discoveryMgr, LeaseRenewalManager
leaseMgr)
That doesn't take a configuration file. Perhaps you meant
LookupDiscoveryManager? Again:
LookupDiscoveryManager(String[] groups, LookupLocator[] locators,
DiscoveryListener listener)
That has a constructor that doesn't require a configuration file.
>
> Regards
> Ashutosh Singh
>
>
>> Date: Thu, 15 Dec 2011 13:00:22 +0000
>> Subject: Re: what should be written in a config file for service application?
>> From: dan.creswell@gmail.com
>> To: user@river.apache.org
>>
>> Okay so then you don't need to put anything in a configuration file.
>> You can hard-code the lot and then come back and do configuration
>> later as it makes sense.
>>
>> Probably the simplest you can go is to use lookuplocators to find the
>> lookup service and register/lookup.
>>
>> On 15 December 2011 12:54, Ashutosh Singh <dh...@hotmail.com> wrote:
>> >
>> > The hello example given contains a complicated server with all the smart proxies and different methods of exporting.
>> >
>> > So I am just writing a very basic Hello World application that uses a jeri protocol. No SDM's!.
>> >
>> >
>> >
>> >
>> >
>> >> Date: Thu, 15 Dec 2011 12:47:58 +0000
>> >> Subject: Re: what should be written in a config file for service application?
>> >> From: dan.creswell@gmail.com
>> >> To: user@river.apache.org
>> >>
>> >> Are you configuring one of the standard services, one of your own or
>> >> one of the examples?
>> >>
>> >> On 15 December 2011 11:36, Ashutosh Singh <dh...@hotmail.com> wrote:
>> >> >
>> >> > Hi,
>> >> >
>> >> > I am a novice RIVER user?
>> >> >
>> >> > Can you please tell me what should be written in a config file for a service application?
>> >> >
>> >> > Regards
>> >> > Ashutosh Singh
>> >> >
>> >
>
RE: what should be written in a config file for service application?
Posted by Ashutosh Singh <dh...@hotmail.com>.
Hi,
I am trying to do that. here is my code.
///////////////////////Service Class/////////////
public class Server implements Hello{
private LookupDiscoveryManager ldm = null;
public Server() throws IOException{
init();
}
@Override
public String sayHello() {
// TODO Auto-generated method stub
return "Hello World";
}
public void init() throws IOException{
System.out.println("in server main");
Exporter myExporter = new BasicJeriExporter(TcpServerEndpoint.getInstance(0), new BasicILFactory());
// Create a service id as required by the join Manager
Uuid myuuid = UuidFactory.generate();
ServiceID myService = new ServiceID(myuuid.getMostSignificantBits(), myuuid.getLeastSignificantBits());
//Create the object proxy for use by joiinmanager
Server myProxy = (Server) myExporter.export(this);
//find the reggie instances
LookupLocator[] myLocator = new LookupLocator[]{new LookupLocator("jini://localhost:8080")};
ldm = new LookupDiscoveryManager(DiscoveryGroupManagement.ALL_GROUPS, myLocator,null );
//Now join them
}
public static void main(String[] args) throws IOException {
}
}
/************** *****************/
Now as the Join Manager takes 4 arguments and since I am not using a config file .
How can I provide entry attr sets . From the documentation I found that
"attrSets - array of Entry consisting of the
attribute sets with which to register the service"
But with Entry Interface i don't know what to write.
Please tell what will go in an entry?
Also can I provide the config argument of JoinManager as null?
Regards
Ashutosh Singh
> Date: Thu, 15 Dec 2011 13:00:22 +0000
> Subject: Re: what should be written in a config file for service application?
> From: dan.creswell@gmail.com
> To: user@river.apache.org
>
> Okay so then you don't need to put anything in a configuration file.
> You can hard-code the lot and then come back and do configuration
> later as it makes sense.
>
> Probably the simplest you can go is to use lookuplocators to find the
> lookup service and register/lookup.
>
> On 15 December 2011 12:54, Ashutosh Singh <dh...@hotmail.com> wrote:
> >
> > The hello example given contains a complicated server with all the smart proxies and different methods of exporting.
> >
> > So I am just writing a very basic Hello World application that uses a jeri protocol. No SDM's!.
> >
> >
> >
> >
> >
> >> Date: Thu, 15 Dec 2011 12:47:58 +0000
> >> Subject: Re: what should be written in a config file for service application?
> >> From: dan.creswell@gmail.com
> >> To: user@river.apache.org
> >>
> >> Are you configuring one of the standard services, one of your own or
> >> one of the examples?
> >>
> >> On 15 December 2011 11:36, Ashutosh Singh <dh...@hotmail.com> wrote:
> >> >
> >> > Hi,
> >> >
> >> > I am a novice RIVER user?
> >> >
> >> > Can you please tell me what should be written in a config file for a service application?
> >> >
> >> > Regards
> >> > Ashutosh Singh
> >> >
> >
Re: what should be written in a config file for service application?
Posted by Dan Creswell <da...@gmail.com>.
Okay so then you don't need to put anything in a configuration file.
You can hard-code the lot and then come back and do configuration
later as it makes sense.
Probably the simplest you can go is to use lookuplocators to find the
lookup service and register/lookup.
On 15 December 2011 12:54, Ashutosh Singh <dh...@hotmail.com> wrote:
>
> The hello example given contains a complicated server with all the smart proxies and different methods of exporting.
>
> So I am just writing a very basic Hello World application that uses a jeri protocol. No SDM's!.
>
>
>
>
>
>> Date: Thu, 15 Dec 2011 12:47:58 +0000
>> Subject: Re: what should be written in a config file for service application?
>> From: dan.creswell@gmail.com
>> To: user@river.apache.org
>>
>> Are you configuring one of the standard services, one of your own or
>> one of the examples?
>>
>> On 15 December 2011 11:36, Ashutosh Singh <dh...@hotmail.com> wrote:
>> >
>> > Hi,
>> >
>> > I am a novice RIVER user?
>> >
>> > Can you please tell me what should be written in a config file for a service application?
>> >
>> > Regards
>> > Ashutosh Singh
>> >
>
RE: what should be written in a config file for service application?
Posted by Ashutosh Singh <dh...@hotmail.com>.
The hello example given contains a complicated server with all the smart proxies and different methods of exporting.
So I am just writing a very basic Hello World application that uses a jeri protocol. No SDM's!.
> Date: Thu, 15 Dec 2011 12:47:58 +0000
> Subject: Re: what should be written in a config file for service application?
> From: dan.creswell@gmail.com
> To: user@river.apache.org
>
> Are you configuring one of the standard services, one of your own or
> one of the examples?
>
> On 15 December 2011 11:36, Ashutosh Singh <dh...@hotmail.com> wrote:
> >
> > Hi,
> >
> > I am a novice RIVER user?
> >
> > Can you please tell me what should be written in a config file for a service application?
> >
> > Regards
> > Ashutosh Singh
> >
Re: what should be written in a config file for service application?
Posted by Dan Creswell <da...@gmail.com>.
Are you configuring one of the standard services, one of your own or
one of the examples?
On 15 December 2011 11:36, Ashutosh Singh <dh...@hotmail.com> wrote:
>
> Hi,
>
> I am a novice RIVER user?
>
> Can you please tell me what should be written in a config file for a service application?
>
> Regards
> Ashutosh Singh
>
Re: what should be written in a config file for service application?
Posted by Tom Hobbs <tv...@googlemail.com>.
Hi,
I don't have any to hand. Your best bet would be to look in distribution
in the directory examples/hello/config and modify one of those to see what
you need.
Sorry, that directory path is from memory so might be a bit wrong.
Hope the helps.
Tom
Grammar and spelling have been sacrificed on the altar of messaging via
mobile device.
On 15 Dec 2011 11:37, "Ashutosh Singh" <dh...@hotmail.com> wrote:
>
> Hi,
>
> I am a novice RIVER user?
>
> Can you please tell me what should be written in a config file for a
> service application?
>
> Regards
> Ashutosh Singh
>