directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pierre-Luc Lacroix (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (DIRSERVER-1949) Cannot add Entry to CoreSession from custom Search Interceptor
Date Thu, 23 Jan 2014 18:26:37 GMT

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

Pierre-Luc Lacroix edited comment on DIRSERVER-1949 at 1/23/14 6:24 PM:
------------------------------------------------------------------------

Something interesting happened when I made that change (moving my custom SearchInterceptor
around), the filter seems to be transformed to an all lower case value of the exact same filter.

For example, my ldapsearch test had the following filter:
"(&(cn=test_user_31)(ou=MYSITE_site))"

But my interceptor's search method received the following filter (opContext.getFilter())
(&(cn=test_user_31)(ou=mysite_site))

I am currently working on creating a test file, hopefully that will help.

Edit: Forgot to mention that moving around the custom interceptor to the spot before the "OperationalInterceptor"
unfortunately did not resolve the issue.
If I remove the line:
{code}
service.getPartitionNexus().add( addContext );
{code}
Then the thread blocks. If I leave the line there, the same exception is thrown.


was (Author: pll.lacroix):
Something interesting happened when I made that change (moving my custom SearchInterceptor
around), the filter seems to be transformed to an all lower case value of the exact same filter.

For example, my ldapsearch test had the following filter:
"(&(cn=test_user_31)(ou=MYSITE_site))"

But my interceptor's search method received the following filter (opContext.getFilter())
(&(cn=test_user_31)(ou=mysite_site))

I am currently working on creating a test file, hopefully that will 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
>         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
(v6.1.5#6160)

Mime
View raw message