[jira] [Comment Edited] (DIRSERVER-1949) Cannot add Entry to CoreSession from custom Search Interceptor

["Emmanuel Lecharny (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DIRSERVER-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13879307#comment-13879307 ] 

Emmanuel Lecharny edited comment on DIRSERVER-1949 at 6/6/19 2:25 PM:
----------------------------------------------------------------------

No, you can't do that. Again, the OperationManager is written in a way that you can't call it from inside the server, because we have no way to know if it's an internal or an external call (and we must protect the server against concurrent modification).

Although if you really want to bypass this lock, you can do :

{code:java}
        AddOperationContext addContext = new AddOperationContext( service.getAdminSession(), entry );

        Interceptor head = directoryService.getInterceptor( addContext.getNextInterceptor() );

       head.add( addContext );
{code}

that should do the trick.

(Here, we create a new operation context, we extract the first interceptor to call, and we directly call it without going through the OperationManager, bypassing the lock.



was (Author: elecharny):
No, you can't do that. Again, the OperationManager is written in a way that you can't call it from inside the server, because we have no way to know if it's an internal or an external call (and we must protect the server against concurrent modification).

Although if you really want to bypass this lock, you can do :

        AddOperationContext addContext = new AddOperationContext( service.getAdminSession(), entry );

        Interceptor head = directoryService.getInterceptor( addContext.getNextInterceptor() );

       head.add( addContext );

that should do the trick.

(Here, we create a new operation context, we extract the first interceptor to call, and we directly call it without going through the OperationManager, bypassing the lock.


> 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:
> // 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
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@directory.apache.org
For additional commands, e-mail: dev-help@directory.apache.org