[prev in list] [next in list] [prev in thread] [next in thread] 

List:       forgerock-opendj
Subject:    [Opendj] OpenDJ LDAP SDK threading model questions
From:       Dave <dave.davoren () gmail ! com>
Date:       2015-10-21 11:03:39
Message-ID: 5627710B.80304 () gmail ! com
[Download RAW message or body]

Hi,

I have been evaluating the LDAP SDK server side API and have the 
following questions on the threading model.

1. When a read is done from a connection, the interest in a read event 
is removed for that connection from the SelectorRunner via the call to 
DefaultSelectorHandler.deregisterKeyInterest(...). However, the interest 
in the read event is not added back until the the event processing is 
complete. This is the case for the Same-thread and Worker-thread 
IOStrategies. There is no issue if the processing is done via the 
same-thread strategy but for the Worker-thread strategy if there is a 
single connection with multiple concurrent LDAP requests, the system is 
limited to executing them serially due to this behavior. Does the API 
support setting up Worker-thread IOStrategy but allow multiple requests 
to be processed concurrently, i.e. the connection can be read again 
while the worker thread processes the previous request?

2. I see in the grizzly framework, there is an async write queue 
available. However, the call to configureConnection from the 
LDAPServerFilter.handleAccept(...) method sets all new connections to 
blocking. This means the async write queue is never used and calls to 
write will always write directly to the socket. I tried to configure the 
"optimizedForMultiplexing" setting in the TCPNIOTransport object that is 
stored in the LDAPListenerOptions but it had no effect due to the fact 
the connection is always set to blocking. Is there any configuration 
available in order to use the async write queue and not write directly 
to the socket?

The reason for the questions is the use case I have will have a small 
number of connections with a high number of requests. I need to be able 
to process requests from the same connection concurrently within the 
grizzly thread pool or within a thread pool managed outside of the 
grizzly and OpenDJ frameworks i.e. use Same-thread IO strategy in 
grizzly and have the processing done in an externally managed thread 
pool. The responses would then be written from the context of an 
externally managed thread pool thread. This is for legacy reasons.

Any help is much appreciated.

Thank you,
Dave.
_______________________________________________
OpenDJ mailing list
OpenDJ@forgerock.org
https://lists.forgerock.org/mailman/listinfo/opendj
[prev in list] [next in list] [prev in thread] [next in thread]