[
https://issues.apache.org/jira/browse/DIRSERVER-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny updated DIRSERVER-1949:
-----------------------------------------
Description:
I have a custom Search Interceptor:
private class SearchInterceptor extends BaseInterceptor
When a use is said to be allowed to login, I basically inject the user into my
cache:
{code:java}
// We do not actually inject it, we give it to the JIT write-through
// cache which will inject it only once, then delete after a timeout.
//private final JitLdapWritethroughCache _jitLdapCache
_jitLdapCache.insert(entryUser);
{code}
Which basically does:
{code:java}
// private DirectoryService service;
service.getAdminSession().add(e);
{code}
The line "service.getAdminSession().add(e);" basically locks up my thread
(won't respond to my search request) and won't allow any other request to go
through.
If I look at the stack, it blocks at the following line (line 390 -
DefaultOperationManager)
{code:java}
// Call the Add method
Interceptor head = directoryService.getInterceptor(
addContext.getNextInterceptor() );
lockWrite();
{code}
and
{code:java}
public void lockWrite()
{
rwLock.writeLock().lock();
}
{code}
This code all ran on the "Thread [pool-4-thread-1]" thread.
Before running "service.getAdminSession().add(e)" I ran:
{code:java}
Trace.info(service.getOperationManager().getRWLock().toString());
{code}
Which outputted:
{code:java}
5398 [main] INFO com.rbccm.authhelper.ldap.ServerRunner - [testinstanceid]
java.util.concurrent.locks.ReentrantReadWriteLock@7177600e[Write locks = 0,
Read locks = 0]
{code}
Thank you for your help.
was:
I have a custom Search Interceptor:
private class SearchInterceptor extends BaseInterceptor
When a use is said to be allowed to login, I basically inject the user into my
cache:
// We do not actually inject it, we give it to the JIT write-through
// cache which will inject it only once, then delete after a timeout.
//private final JitLdapWritethroughCache _jitLdapCache
_jitLdapCache.insert(entryUser);
Which basically does:
// private DirectoryService service;
service.getAdminSession().add(e);
The line "service.getAdminSession().add(e);" basically locks up my thread
(won't respond to my search request) and won't allow any other request to go
through.
If I look at the stack, it blocks at the following line (line 390 -
DefaultOperationManager)
// Call the Add method
Interceptor head = directoryService.getInterceptor(
addContext.getNextInterceptor() );
lockWrite();
and
public void lockWrite()
{
rwLock.writeLock().lock();
}
This code all ran on the "Thread [pool-4-thread-1]" thread.
Before running "service.getAdminSession().add(e)" I ran:
Trace.info(service.getOperationManager().getRWLock().toString());
Which outputted:
5398 [main] INFO com.rbccm.authhelper.ldap.ServerRunner - [testinstanceid]
java.util.concurrent.locks.ReentrantReadWriteLock@7177600e[Write locks = 0,
Read locks = 0]
Thank you for your help.
> Cannot add Entry to CoreSession from custom Search Interceptor
> --------------------------------------------------------------
>
> Key: DIRSERVER-1949
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1949
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: core
> Affects Versions: 2.0.0-M15
> Reporter: Pierre-Luc Lacroix
> Priority: Major
> Attachments: Interceptors.jpg
>
>
> I have a custom Search Interceptor:
> private class SearchInterceptor extends BaseInterceptor
> When a use is said to be allowed to login, I basically inject the user into
> my cache:
> {code:java}
> // We do not actually inject it, we give it to the JIT write-through
> // cache which will inject it only once, then delete after a timeout.
> //private final JitLdapWritethroughCache _jitLdapCache
> _jitLdapCache.insert(entryUser);
> {code}
> Which basically does:
> {code:java}
> // private DirectoryService service;
> service.getAdminSession().add(e);
> {code}
> The line "service.getAdminSession().add(e);" basically locks up my thread
> (won't respond to my search request) and won't allow any other request to go
> through.
> If I look at the stack, it blocks at the following line (line 390 -
> DefaultOperationManager)
> {code:java}
> // Call the Add method
> Interceptor head = directoryService.getInterceptor(
> addContext.getNextInterceptor() );
> lockWrite();
> {code}
> and
> {code:java}
> public void lockWrite()
> {
> rwLock.writeLock().lock();
> }
> {code}
> This code all ran on the "Thread [pool-4-thread-1]" thread.
> Before running "service.getAdminSession().add(e)" I ran:
> {code:java}
> Trace.info(service.getOperationManager().getRWLock().toString());
> {code}
> Which outputted:
> {code:java}
> 5398 [main] INFO com.rbccm.authhelper.ldap.ServerRunner - [testinstanceid]
> java.util.concurrent.locks.ReentrantReadWriteLock@7177600e[Write locks = 0,
> Read locks = 0]
> {code}
> Thank you for your help.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
