From: EJP on 7 May 2010 04:28 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 7 May 2010 09:18 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 12 May 2010 09:11 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 28 May 2010 14:10 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 23 Jun 2010 23:29 > 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.
First
|
Prev
|
Pages: 1 2 3 Prev: Spam on Usenet groups Next: Anybody using their Java IDE with the C++ plugin? |