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] [Commented] (DIRSERVER-1949) Cannot add Entry to CoreSession from custom Search Interceptor
Date Wed, 22 Jan 2014 22:16:19 GMT

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

Pierre-Luc Lacroix commented on DIRSERVER-1949:
-----------------------------------------------

Merci pour la réponse rapide Emmanuel.

I am currently porting an application that used to be running on ApacheDS 1.5.5 to version
2.0, perhaps this explains why some of these things were coded the way they are (I am not
the original author of the application running on ApacheDS 1.5.5).

So if I understood correctly, I cannot call:

service.getAdminSession().add(entry);

>From my custom SearchInterceptor? What would be the right way (with ApacheDS 2.0) to add
my Entry now?


Perhaps some (simplified) code would help (please ignore if not):

public EntryFilteringCursor search( SearchOperationContext opContext ) throws LdapException
{

    final String filter = String.valueOf(opContext.getFilter());
    final String parentDn = opContext.getDn().toString();
    final String vpn = DnUtils.extractVpnFromSearchFilter(filter);

Dn dnBaseVpn = new Dn(String.format("ou=%s,%s", vpn, parentDn));
Entry entryBaseVpn = service.newEntry(dnBaseVpn);
entryBaseVpn.add("objectClass", "top", "organizationalUnit", "extensibleObject");
entryBaseVpn.add("ou", vpn);
				
// Blocks
service.getAdminSession().add(entryBaseVpn);

return super.search(opContext);
}

> 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)

Mime
View raw message