You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Emmanuel Lecharny (JIRA)" <ji...@apache.org> on 2019/06/06 14:29:00 UTC

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

     [ 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-unsubscribe@directory.apache.org
For additional commands, e-mail: dev-help@directory.apache.org