From: EJP on
On 7/05/2010 2:52 PM, FutureScalper wrote:
> I am calling that TCPEndpoint
> static method sun.rmi.transport.tcp.TCPEndpoint
> public static void shedConnectionCaches() hoping to "harvest" or
> recycle whatever may lurk in the connection caches :)

Don't do that.

> com.twc.remote.RemoteIndicatorServiceImpl_Stub.getLastAct(Unknown
> Source)<---
> com.twc.remote.RemoteIndicatorServiceImpl_Stub.getActFastMacdTrend(Unknown
> com.twc.remote.RemoteIndicatorServiceImpl_Stub.getBidRunLengthFast(Unknown
> com.twc.remote.RemoteIndicatorServiceImpl_Stub.getLastAct(Unknown
> com.twc.remote.RemoteIndicatorServiceImpl_Stub.getActFastMacdTrend(Unknown

None of these has anything to do with the Registry so I don't know why
you thought restarting the Registry would do anything. They are all in
calls to the *same* remote object, RemoteIndicatorService. So is that
one doing something odd? like deadlocking itself?

BTW are all these objects exported on the same port? They should be.
From: FutureScalper on
On May 7, 4:28 am, EJP <esmond.not.p...(a)not.bigpond.com> wrote:
> On 7/05/2010 2:52 PM, FutureScalper wrote:
>
> > I am calling that TCPEndpoint
> > static method sun.rmi.transport.tcp.TCPEndpoint
> > public static  void shedConnectionCaches() hoping to "harvest" or
> > recycle whatever may lurk in the connection caches :)
>
> Don't do that.
>
> > com.twc.remote.RemoteIndicatorServiceImpl_Stub.getLastAct(Unknown
> > Source)<---
> > com.twc.remote.RemoteIndicatorServiceImpl_Stub.getActFastMacdTrend(Unknown
> > com.twc.remote.RemoteIndicatorServiceImpl_Stub.getBidRunLengthFast(Unknown
> > com.twc.remote.RemoteIndicatorServiceImpl_Stub.getLastAct(Unknown
> > com.twc.remote.RemoteIndicatorServiceImpl_Stub.getActFastMacdTrend(Unknown
>
> None of these has anything to do with the Registry so I don't know why
> you thought restarting the Registry would do anything. They are all in
> calls to the *same* remote object, RemoteIndicatorService. So is that
> one doing something odd? like deadlocking itself?
>
> BTW are all these objects exported on the same port? They should be.

I thank you for the suggestions.

No, concurrency is not an issue, and no deadlocks taking place as far
as I know and this whole thing is highly threads tolerant.

I have enough suggestions to work on and I'm also not reproducing the
issue myself since last post.

I'll try and break it again by having a couple of them heavily cross-
referencing each other.

Appreciate your help, will post resolution if I find one.
From: FutureScalper on
On May 7, 9:18 am, FutureScalper <futurescal...(a)gmail.com> wrote:
> On May 7, 4:28 am, EJP <esmond.not.p...(a)not.bigpond.com> wrote:
>
>
>
>
>
> > On 7/05/2010 2:52 PM, FutureScalper wrote:
>
> > > I am calling that TCPEndpoint
> > > static method sun.rmi.transport.tcp.TCPEndpoint
> > > public static  void shedConnectionCaches() hoping to "harvest" or
> > > recycle whatever may lurk in theconnectioncaches :)
>
> > Don't do that.
>
> > > com.twc.remote.RemoteIndicatorServiceImpl_Stub.getLastAct(Unknown
> > > Source)<---
> > > com.twc.remote.RemoteIndicatorServiceImpl_Stub.getActFastMacdTrend(Unknown
> > > com.twc.remote.RemoteIndicatorServiceImpl_Stub.getBidRunLengthFast(Unknown
> > > com.twc.remote.RemoteIndicatorServiceImpl_Stub.getLastAct(Unknown
> > > com.twc.remote.RemoteIndicatorServiceImpl_Stub.getActFastMacdTrend(Unknown
>
> > None of these has anything to do with the Registry so I don't know why
> > you thought restarting the Registry would do anything. They are all in
> > calls to the *same* remote object, RemoteIndicatorService. So is that
> > one doing something odd? like deadlocking itself?
>
> > BTW are all these objects exported on the same port? They should be.
>
> I thank you for the suggestions.
>
> No, concurrency is not an issue, and no deadlocks taking place as far
> as I know and this whole thing is highly threads tolerant.
>
> I have enough suggestions to work on and I'm also not reproducing the
> issue myself since last post.
>
> I'll try and break it again by having a couple of them heavily cross-
> referencing each other.
>
> Appreciate your help, will post resolution if I find one.

Thanks again for suggestions. To avoid possible deadlock, I've just
made the RMI server implementation single-threaded even though it's
read only stuff and should not require synchronization.

Don't think that's the issue, but just as a sanity check.

I've experienced the issue once since last post under fairly heavy
usage so it's hard for me to reproduce.



From: FutureScalper on
On May 7, 9:18 am, FutureScalper <futurescal...(a)gmail.com> wrote:
> On May 7, 4:28 am, EJP <esmond.not.p...(a)not.bigpond.com> wrote:
>
>
>
>
>
> > On 7/05/2010 2:52 PM, FutureScalper wrote:
>
> > > I am calling that TCPEndpoint
> > > static method sun.rmi.transport.tcp.TCPEndpoint
> > > public static  void shedConnectionCaches() hoping to "harvest" or
> > > recycle whatever may lurk in theconnectioncaches :)
>
> > Don't do that.
>
> > > com.twc.remote.RemoteIndicatorServiceImpl_Stub.getLastAct(Unknown
> > > Source)<---
> > > com.twc.remote.RemoteIndicatorServiceImpl_Stub.getActFastMacdTrend(Unknown
> > > com.twc.remote.RemoteIndicatorServiceImpl_Stub.getBidRunLengthFast(Unknown
> > > com.twc.remote.RemoteIndicatorServiceImpl_Stub.getLastAct(Unknown
> > > com.twc.remote.RemoteIndicatorServiceImpl_Stub.getActFastMacdTrend(Unknown
>
> > None of these has anything to do with the Registry so I don't know why
> > you thought restarting the Registry would do anything. They are all in
> > calls to the *same* remote object, RemoteIndicatorService. So is that
> > one doing something odd? like deadlocking itself?
>
> > BTW are all these objects exported on the same port? They should be.
>
> I thank you for the suggestions.
>
> No, concurrency is not an issue, and no deadlocks taking place as far
> as I know and this whole thing is highly threads tolerant.
>
> I have enough suggestions to work on and I'm also not reproducing the
> issue myself since last post.
>
> I'll try and break it again by having a couple of them heavily cross-
> referencing each other.
>
> Appreciate your help, will post resolution if I find one.

I've been thinking about this issue, and I suspect that the RMI socket
reader thread may be crashing for some unknown reason. I don't have
any direct evidence of this right now, but I smell something like that
happening.

So, I'll look into how I can determine that, and possibly implement my
own more reliable RMI reader thread is that's the issue. Can't think
of anything else that would cause this situation, other than the
socket reader thread dying within my client process (acting as a
server).

From: Esmond Pitt on
> I've been thinking about this issue, and I suspect that the RMI socket
> reader thread may be crashing for some unknown reason. I don't have
> any direct evidence of this right now, but I smell something like that
> happening.

*I* smell the remote object deadlocking itself so that nothing can
proceed. You don't have any evidence about the RMI reader thread
crashing and I have personally never seen it in 13 years of RMI. And why
would it only crash for one specific remote object? Obviously the
problem is associated with that object, not the RMI system. You're
barking up the wrong tree.

> Can't think of anything else that would cause this situation

I had already made the suggestion above.