[
https://issues.apache.org/jira/browse/DIRSERVER-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13879230#comment-13879230
]
Emmanuel Lecharny commented on DIRSERVER-1949:
----------------------------------------------
This is plain normal. Calling getAdminSession().add(e) will re-enter into a
protected section. You should simply add your entry into your cache in your
interceptor.
The rational for this lock is that we need to protect the database against
concurrent modifications, thus any modifications done (add/delete/modify) are
serialized using the rwLock (this will change very soon).
Now, I'm not sure why you would add a cache in your search interceptor, when we
already have a entry cache down in the AsbtractBTreePartition.
> 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
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
