FWD » Core Development » User Interface

See #3552-113, #3552-114, #3552-115, #3552-116 and others. The idea here is the PSTimer thread is left with this stacktrace after the client session terminates:

Object.wait(long) line: not available [native method]    
WaitingThread.waitMessage(int) line: 155    
Queue.transactImpl(Message, int) line: 1180    
Queue.transact(Message, int) line: 657    
DirectSession(BaseSession).transact(Message, int) line: 271    
HighLevelObject.transact(RoutingKey, Object[]) line: 211    
RemoteObject$RemoteAccess.invokeCore(Object, Method, Object[]) line: 1473    
RemoteObject$RemoteAccess(InvocationStub).invoke(Object, Method, Object[]) line: 145    
$Proxy16.postServerEvent(ServerEvent) line: not available    
LogicalTerminal.postServerEvent(ServerEvent) line: 7542    
PSTimer.fireEvent() line: 648    
PSTimer.run() line: 594
AssociatedThread.run() line: 175   

This must not happen, even if the business logic doesn't clean up this resource explicitly - this resource is a client-side resource emulated on server-side, and it must be destroyed when the client is terminated.

The root cause is that the thread is registered as a thread which can make async requests within the same context, and Queue.stopTransport does not notify these async threads - it does this only if the context is is non-conversation mode, which is incorrect; we can have async requests in conversation mode, too.

From #3552-118:

Constantin Asofiei wrote:

Greg Shah wrote:

The notifyPWD is supposed to notify any thread sending async messages to the remote side. But this is done only in non-Conversation threads - I think we should do this for Conversation mode, too. Greg?

I don't think this will help. The notifyPWT() is really just the equivalent of the conversation.halt() but for non-conversation threads. It won't notify any AssociatedThreads. Rather, it just unblocks threads that are waiting for a response from the peer side through the DAP. Any thread that is blocked waiting for some other JVM event will not be affected.

Any thread sending async messages is registered in Queue.pwt map: this includes the PSTimer thread, which is an AssociatedThread registered for async messages. If a Conversation-mode context creates async threads, these will be registered to Queue.pwt - that's why I think notifyPWT is needed.

Your point about asynch messages is a good one. Calling notifyPWT() is a reasonable idea and it should be safe. It will unblock any currently waiting threads. What happens then? How to the now-unblocked threads know that they need to exit?

In addition, what about an AssociatedThread that is not currently waiting in the PWT but is actively running?

Did branch 3750b resolve this issue?

Greg Shah wrote:

Did branch 3750b resolve this issue?

Yes.