Is the Sun JNDI LDAP provider thread safe?

Hi,
The JNDI documentation states that the Context implementation is not required to be thread safe although some providers provide thread safety. My question is whether the Sun JNDI LDAP provider is thread safe or do we have to synchronize on the Context instance?
Thanks

Read this: http://java.sun.com/j2se/1.3/docs/api/javax/naming/Context.html
The answer, I think is no you need to synchronize accesses yourself. If you're using it from a servlet container, this should be OK, since each request is on a separate thread.

Similar Messages

  • NullPointerException at com.sun.jndi.ldap.Connection.run(Connection.java:52

    We are using the Sun jndi 1.2.1 files from a Java client to
    access the IBM SecureWay Directory 3.2 server. Our test case is
    retrieving entries using the ctx.getAttributes (String, String[])
    method. Occasionally we are receiving the following error.
    java.lang.NullPointerException
    at com.sun.jndi.ldap.Connection.run(Connection.java:525)
    at java.lang.Thread.run(Thread.java:481)
    The java.lang.NullPointerException is coming from the Sun JNDI file.
    Our program is not catching this exception.
    Has anyone seen this problem before and have any ideas on how this can be resolved?

    Download and use LDAP 1.2.3 or JDK 1.3.1.
    The problem should go away.

  • Message: Cannot begin session. com/sun/jndi/ldap/ctl/PagedResultsControl

    When I try to request a simple reuest (getversion) from the drm wsdl I receive an error in the XML repsonse (see below).
    I read somewhere in the forum that I have to change the external direcortory provider in HSS from "MSAD" to LDAP/OID. But this can not be configured in HSS since I can not change the ID attribute (its greyed out).
    Does anyone knows how I can sole it: I think its related to: "message: Cannot begin session. com/sun/jndi/ldap/ctl/PagedResultsControl"
    Perhaps wrong or missing jar files in the connection configuration?
    Any help is welcome.
    Detlev
    <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
    <env:Header/>
    <env:Body>
    <env:Fault>
    <faultcode>env:Server</faultcode>
    <faultstring>Cannot getVersion.
    [Tue Feb 14 16:03:06 CET 2012] - Oracle EPM Foundation Agent
    Error in request: begin session (message: Cannot begin session. com/sun/jndi/ldap/ctl/PagedResultsControl)</faultstring>
    <detail>
    <DrmServiceException xmlns="http://drm.webservices.epm.oracle">
    <Message xmlns:ns2="http://drm.webservices.epm.oracle" xmlns="">Cannot getVersion.
    [Tue Feb 14 16:03:06 CET 2012] - Oracle EPM Foundation Agent
    Error in request: begin session (message: Cannot begin session. com/sun/jndi/ldap/ctl/PagedResultsControl)</Message>
    <Code xmlns:ns2="http://drm.webservices.epm.oracle" xmlns="">0</Code>
    </DrmServiceException>
    </detail>
    </env:Fault>
    </env:Body>
    </env:Envelope>

    Thanks for the repsonse.
    Its exactly how you explain it.
    Last thing I am dealing with (as var as I can see now) is getting a (generic/other) ldap connection in HSS to our MSAD.
    HSS userinterface comes up with an error just before showing the user list. (on the serverside I traced traffic (wireshark) and see that userinformation is indeed retrieved).
    But the frontend is juist not showing/ loading the information.
    the error"a communication error occured when loading the view pane" Than the screen keeps on loading for ever
    Oracle support tries to find out whats going wrong here.
    Detlev

  • Need javadoc for com.sun.jndi.ldap.ctl.*?

    Hi,
    has anybody the javadoc for the above named package?
    I need at first com.sun.jndi.ldap.ctl.SortKey.
    It is needed to get a sorted search result from a LDAP server.
    Thank you for your help.
    Fredi

    Download the LDAP provider at
    http://java.sun.com/products/jndi/#download
    See the README-LDAP.txt in the bundle.
    It says that the javadocs for the controls are
    at doc/ldapcontrols.

  • Com.sun.jndi.ldap

    Hi,
    Is anyone familiar with JNDI LDAP automatic discovery codes
    env.put(Context.PROVIDER_URL,
        ldap:///o=JNDITutorial,dc=example,dc=com);
    It seems that by using DNS that associate with multiple domain controllers, it would lock out user account if they enter wrong pw because LDAP provider will send the request to each of the associated DC at the same time.  I wonder if anyone run through this issue and if it is a JDK bug and if someone does, how to you work around it?
    Thanks,
    Jennifer

    Hi,
    did you also try the following timeout variables?
    env.put("com.sun.jndi.dns.timeout.initial", "2000");
    env.put("com.sun.jndi.dns.timeout.retries", "3");...
    Besides you specific problem you will find a probably interesting article about handling network timeouts her:
    http://www.javacoffeebreak.com/articles/network_timeouts/
    Regards
    Klaus

  • Com.sun.jndi.ldap.ctl.PagedResultsControl

    Hi,
    I was wondering if iPlanet Server Directory 5.0 SP1 supports the Page Result
    Control?
    I am developing a Java Client that will read more than 2 000 entries from
    iPlanet.
    I have an OperationNotSupportedException with iPlanet 5.0.
    Thanks in advance.
    Stephane Chauvin.

    Hello Stephane,
    No, it is not. You can list the supported controls by executing an ldapsearch on the root DSE.<br>
    <i>ldapsearch -h <serverhost> -p <serverport> -s base -b "" \<br>"objectclass=*" supportedcontrol</i><br>
    Instead of the Page Result Control, you may want to consider using the Virtual List View control (see http://search.ietf.org/internet-drafts/draft-ietf-ldapext-ldapv3-vlv-04.txt)
    Regards,
    Bertold

  • Is the Illustrator SDK thread-safe?

    After searching this forum and the Illustrator SDK documentation, I can't find any references to a discussion about threading issues using the Illustrator C++ SDK. There is only a reference in some header files as to whether menu text is threaded, without any explanation.
    I take this to mean that probably the Illustrator SDK is not "thread-safe" (i.e., it is not safe to make API calls from arbitrary threads; you should only call the API from the thread that calls into your plug-in). Does anyone know this to be the case, or not?
    If it is the case, the normal way I'd write a plug-in to respond to requests from other applications for drawing services would be through a mutex-protected queue. In other words, when Illustrator calls the plug-in at application startup time, the plug-in could set up a mutually exclusive lock (a mutex), start a thread that could respond to requests from other applications, and request periodic idle processing time from the application. When such a request arrived from another application at an arbitrary time, the thread could respond by locking the queue, adding a request to the queue for drawing services in some format that the plug-in would define, and unlocking the queue. The next time the application called the plugin with an idle event, the queue could be locked, pulled from, and unlocked. Whatever request had been pulled could then be serviced with Illustrator API calls. Does anyone know whether that is a workable strategy for Illustrator?
    I assume it probably is, because that seems to be the way the ScriptingSupport.aip plug-in works. I did a simple test with three instances of a Visual Basic generated EXE file. All three were able to make overlapping requests to Illustrator, and each request was worked upon in turn, with intermediate results from each request arriving in turn. This was a simple test to add some "Hello, World" text and export some jpegs,
    repeatedly.
    Any advice would be greatly appreciated!
    Glenn Picher
    Dirigo Multimedia, Inc.
    [email protected]

    Zac Lam wrote:
    The Memory Suite does pull from a specific memory pool that is set based on the user-specified Memory settings in the Preferences.  If you use standard OS calls, then you could end up allocating memory beyond the user-specified settings, whereas using the Memory Suite will help you stick to the Memory settings in the Preferences.
    When you get back NULL when allocating memory, are you hitting the upper boundaries of your memory usage?  Are you getting any error code returned from the function calls themselves?
    I am not hitting the upper memory bounds - I have several customers that have 10's of Gb free.
    There is no error return code from the ->NewPtr() call.
         PrMemoryPtr (*NewPtr)(csSDK_uint32 byteCount);
    A NULL pointer is how you detect a problem.
    Note that changing the size of the ->ReserveMemory() doesn't seem to make any difference as to whether you'll get a memory ptr or NULL back.
    btw my NewPtr size is either
         W x H x sizeof(PrPixelFormat_YUVA4444_32f)
         W x H x sizeof(PrPixelFormat_YUVA4444_8u)
    and happens concurrently on #cpu's threads (eg 16 to 32 instances at once is pretty common).
    The more processing power that the nVidia card has seems to make it fall over faster.
    eg I don't see it at all on a GTS 250 but do on a GTX 480, Quadro 4000 & 5000 and GTX 660
    I think there is a threading issue and an issue with the Memory Suite's pool and how it interacts with the CUDA memory pool. - note that CUDA sets RESERVED (aka locked) memory which can easily cause a fragmenting problem if you're not using the OS memory handler.

  • Is the Memory Suite thread safe?

    Hi all,
    Is the memory suite thread safe (at least when used from the Exporter context)?
    I ask because I have many threads getting and freeing memory and I've found that I get back null sometimes. This, I suspect, is the problem that's all the talk in the user forum with CS6 crashing with CUDA enabled. I'm starting to suspect that there is a memory management problem when there is also a lot of memory allocation and freeing going on by the CUDA driver. It seems that the faster the nVidia card the more likely it is to crash. That would suggest the CUDA driver (ie the code that manages the scheduling of the CUDA kernels) is in some way coupled to the memory use by Adobe or by Windows alloc|free too.
    I replaced the memory functions with _aligned_malloc|free and it seems far more reliable. Maybe it's because the OS malloc|free are thread safe or maybe it's because it's pulling from a different pool of memory (vs the Memory Suite's pool or the CUDA pool)
    comments?
    Edward

    Zac Lam wrote:
    The Memory Suite does pull from a specific memory pool that is set based on the user-specified Memory settings in the Preferences.  If you use standard OS calls, then you could end up allocating memory beyond the user-specified settings, whereas using the Memory Suite will help you stick to the Memory settings in the Preferences.
    When you get back NULL when allocating memory, are you hitting the upper boundaries of your memory usage?  Are you getting any error code returned from the function calls themselves?
    I am not hitting the upper memory bounds - I have several customers that have 10's of Gb free.
    There is no error return code from the ->NewPtr() call.
         PrMemoryPtr (*NewPtr)(csSDK_uint32 byteCount);
    A NULL pointer is how you detect a problem.
    Note that changing the size of the ->ReserveMemory() doesn't seem to make any difference as to whether you'll get a memory ptr or NULL back.
    btw my NewPtr size is either
         W x H x sizeof(PrPixelFormat_YUVA4444_32f)
         W x H x sizeof(PrPixelFormat_YUVA4444_8u)
    and happens concurrently on #cpu's threads (eg 16 to 32 instances at once is pretty common).
    The more processing power that the nVidia card has seems to make it fall over faster.
    eg I don't see it at all on a GTS 250 but do on a GTX 480, Quadro 4000 & 5000 and GTX 660
    I think there is a threading issue and an issue with the Memory Suite's pool and how it interacts with the CUDA memory pool. - note that CUDA sets RESERVED (aka locked) memory which can easily cause a fragmenting problem if you're not using the OS memory handler.

  • Connection reset when obtaining Realms from LDAP provider

    Properties props = new Properties();
    props.put( "provider", JAZNProvider.Type.LDAP);
    props.put( "location", "ldap://<myoidurl>:389");
    props.put( "ldap.user", "cn=orcladmin");
    props.put( "ldap.password", "!<mypwd>");
    JAZNConfig cfg = new JAZNConfig(props);
    JAZNProvider prov = cfg.getJAZNProvider();
    Set realms = prov.getRealmManager().getRealms(); <---- causes following error
    Exception in thread "main" oracle.security.jazn.JAZNNamingException: The system is unable to communicate with the directory or naming service.
         at oracle.security.jazn.spi.ldap.LDAPContext.getSSLDirContext(LDAPContext.java:622)
         at oracle.security.jazn.spi.ldap.LDAPContext.getDirContext(LDAPContext.java:487)
         at oracle.security.jazn.spi.ldap.LDAPContext.getDefaultDirContext(LDAPContext.java:246)
         at oracle.security.jazn.spi.ldap.LDAPContext.getOrclRootCtxDN(LDAPContext.java:187)
         at oracle.security.jazn.spi.ldap.LDAPContext.getSiteJAZNCtxDN(LDAPContext.java:222)
         at oracle.security.jazn.spi.ldap.LDAPRealmManager.searchRealms(LDAPRealmManager.java:1087)
         at oracle.security.jazn.spi.ldap.LDAPRealmManager.getRealms(LDAPRealmManager.java:200)
         at client.JaznTest.<init>(JaznTest.java:41)
         at client.JaznTest.main(JaznTest.java:54)
    Caused by: javax.naming.CommunicationException: oidtest.ncdenr.org:389 [Root exception is java.net.SocketException: Connection reset]
         at com.sun.jndi.ldap.Connection.<init>(Connection.java:194)
         at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:118)
         at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1578)
         at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2596)
         at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:283)
         at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:175)
         at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:193)
         at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:136)
         at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:66)
         at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
         at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:247)
         at javax.naming.InitialContext.init(InitialContext.java:223)
         at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:134)
         at oracle.security.jazn.spi.ldap.LDAPContext.getSSLDirContext(LDAPContext.java:613)
         ... 8 more
    Caused by: java.net.SocketException: Connection reset
         at java.net.SocketInputStream.read(SocketInputStream.java:168)
         at com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:284)
         at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:319)
         at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:720)
         at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1025)
         at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1038)
         at oracle.security.jazn.spi.ldap.JAZNSSLSocketFactoryImpl.init(JAZNSSLSocketFactoryImpl.java:228)
         at oracle.security.jazn.spi.ldap.JAZNSSLSocketFactoryImpl.createSocket(JAZNSSLSocketFactoryImpl.java:170)
         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:585)
         at com.sun.jndi.ldap.Connection.createSocket(Connection.java:311)
         at com.sun.jndi.ldap.Connection.<init>(Connection.java:181)
         ... 21 more

    The reset seems to happen after 5 minutes. Is there any network device in between 153.88.247.15 and the DPS? It could also be a idle timeout on the box or app on 153.88.247.15

  • Java JNDI LDAP connectivity problem.  NoSuchAttributeException

    Hello,
    I am trying to add a user to Active Directory server through LDAP. Following is the code I am using:
    ======================================================================
    Hashtable env = new Hashtable();
    env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
    env.put(Context.PROVIDER_URL, "ldap://192.123.321.123:389");
    env.put(Context.SECURITY_AUTHENTICATION, "simple");
    env.put(Context.SECURITY_PRINCIPAL, "user1");
    env.put(Context.SECURITY_CREDENTIALS, "user123");
    try {
    System.out.println("68");
    Context ctx = new InitialContext(env);
    System.out.println("71");
    BasicAttribute oc = new BasicAttribute("objectclass", "top");
    oc.add("person");
    oc.add("organizationalperson");
    oc.add("User");
    BasicAttribute ouSet = new BasicAttribute("ou");
    ouSet.add("test");
    BasicAttributes attrs = new BasicAttributes(true);
    attrs.put(oc);
    attrs.put(ouSet);
    attrs.put("cn", "ndubey001");
    attrs.put("sn", "ndubey001");
    attrs.put("sAMAccountName", "ndubey001");
    attrs.put("givenName", "ndubey001");
    attrs.put("name", "ndubey001");
    ctx.bind("uid=ndubey001,ou=test,o=myserver.com", attrs);
    System.out.println("74");
    ctx.close();
    } catch (NamingException e) {
    // TODO Auto-generated catch block
    e.printStackTrace();
    ======================================================================
    I have tried with so many different combinations. Most of the times the parameters I am passing looks okay but I keep getting the same exception as follows:
    ======================================================================
    68
    71
    javax.naming.directory.NoSuchAttributeException: [LDAP: error code 16 - 00000057: LdapErr: DSID-0C090B38, comment: Error in attribute conversion operation, data 0, vece
    at com.sun.jndi.ldap.LdapCtx.mapErrorCode(Unknown Source)
         at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source)
         at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source)
         at com.sun.jndi.ldap.LdapCtx.c_bind(Unknown Source)
         at com.sun.jndi.ldap.LdapCtx.c_bind(Unknown Source)
         at com.sun.jndi.toolkit.ctx.ComponentContext.p_bind(Unknown Source)
         at com.sun.jndi.toolkit.ctx.PartialCompositeContext.bind(Unknown Source)
         at com.sun.jndi.toolkit.ctx.PartialCompositeContext.bind(Unknown Source)
         at javax.naming.InitialContext.bind(Unknown Source)
         at LDAPTest.main(LDAPTest.java:99)Coming out
    ======================================================================
    Can anyone tell what is the exact problem ?
    Cheers,
    Nitin                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

    Too many errors to even consider correcting your code (objectClasses, UID attribute, ctx.create)....
    Refer to the following for a description & sample code:
    JNDI, Active Directory (Creating new users & demystifying userAccountControl
    http://forum.java.sun.com/thread.jspa?threadID=582103&tstart=15

  • JNDI, LDAP, and Weblogic 6.0

    Hi-
    We are encountering an issue with JNDI and spurious "socket closed"
    exceptions. The players in our environment are Weblogic 6.0, Netscape
    Directory Server 4.1, (both running on Solaris 2.8) and JNDI as of JDK 1.3.
    We do JNDI lookups to connect to LDAP and most of the time everything works
    fine. Occasionally we get the following exception.
    java.lang.NullPointerException
    at com.sun.jndi.ldap.Connection.run(Connection.java:568)
    at java.lang.Thread.run(Thread.java:484)
    Exception encountered: Socket closed
    javax.naming.CommunicationException: Socket closed. Root exception is
    java.net.SocketException: Socket closed
    at java.net.SocketOutputStream.socketWrite(Native Method)
    at java.net.SocketOutputStream.write(SocketOutputStream.java:83)
    at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:72)
    at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:130)
    at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:210)
    at com.sun.jndi.ldap.LdapClient.search(LdapClient.java:497)
    at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:1720)
    at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1584)
    at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1509)
    at
    com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.ja
    va:371)
    at
    com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeD
    irContext.java:331)
    at
    com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeD
    irContext.java:316)
    at
    javax.naming.directory.InitialDirContext.search(InitialDirContext.java:241)
    at adpsis.posse.ldap.LDAPReader.find(LDAPReader.java:37)
    at adpsis.posse.prfpos.PreferencesEJB.getUserName(PreferencesEJB.java:589)
    at
    adpsis.posse.prfpos.PreferencesEJB.getColorAttributes(PreferencesEJB.java:39
    1)
    at
    adpsis.posse.prfpos.PreferencesEJB.getColorPreferences(PreferencesEJB.java:3
    02)
    at
    adpsis.posse.prfpos.PreferencesEJBImpl.getColorPreferences(PreferencesEJBImp
    l.java:250)
    at
    adpsis.posse.prfpos.PreferencesEJBEOImpl.getColorPreferences(PreferencesEJBE
    OImpl.java:287)
    at
    adpsis.posse.prfpos.PreferencesEJBEOImpl_WLSkel.invoke(PreferencesEJBEOImpl_
    WLSkel.java:116)
    at
    weblogic.rmi.internal.BasicServerAdapter.invoke(BasicServerAdapter.java:373)
    at
    weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServerRef.java
    :128)
    at
    weblogic.rmi.internal.BasicServerAdapter.invoke(BasicServerAdapter.java:237)
    at
    weblogic.rmi.internal.BasicRequestHandler.handleRequest(BasicRequestHandler.
    java:118)
    at
    weblogic.rmi.internal.BasicRequestDispatcher.dispatch(BasicRequestDispatcher
    .java:115)
    at weblogic.rmi.internal.ServerRequest.sendOneWayRaw(ServerRequest.java:88)
    at weblogic.rmi.internal.ServerRequest.sendReceive(ServerRequest.java:108)
    at
    weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java
    :247)
    at
    weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java
    :225)
    at
    adpsis.posse.prfpos.PreferencesEJBEOImpl_WLStub.getColorPreferences(Preferen
    cesEJBEOImpl_WLStub.java:221)
    at adpsis.posse.transformer.CSSServlet.doPost(CSSServlet.java:86)
    at adpsis.posse.transformer.CSSServlet.doGet(CSSServlet.java:214)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:748)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
    at
    weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java
    :213)
    at
    weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletCo
    ntext.java:1265)
    at
    weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java
    :1631)
    at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
    at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
    The only way to recover is to restart the Weblogic server. The LDAP server
    appears to be running normally and continues to service other instances of
    Weblogic. No errors are logged in the LDAP server, the JNDI lookup that
    establishes the DirContext works fine on restart and is used multiple times
    with no issues until..poof..socket closed. I'm not certain which part is at
    issue, Weblogic, LDAP, or JNDI.
    Any ideas?
    Regards,
    Brett Schmoll
    ADP/SIS

    WLS 6.0 will be supported in the next release of WLCS, which is due in the
    spring.
    - Ginny
    "aamerG" <[email protected]> wrote in message
    news:3a5cb774$[email protected]..
    Hi everyone,
    we are starting a new development project and would like to use Weblogic
    6.0. How soon do you think there we be a version of WLCS which works with
    6.0.
    TIA

  • JNDI/LDAP socket connection life time

    Hi,
    I've got a basic object lookup and search for attributes on that object working. I do this by creating an
    new InitialDirContext
    and then using that context to do a search for att values.
    Now i want to do this for many clients, and using this process over and over suggests to me that a new network connection is made each time.
    I'd like to just keep the connection live, and change my context, how does one to that?

    Ok, a thread can't be complete w/o some code..
    I'm getting errors creating the subcontext
    javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid Credentials]; remaining name 'uid=dmb,ou=people,
    acme.com,dc=ldapdev,dc=acme,dc=com'
    These credentials work fine when they are used as the initial context.
    import javax.naming.*;
    import javax.naming.ldap.*;
    import javax.naming.directory.*;
    import java.util.*;
    public class LDAP2
         public static final String s_PrincipalRoot = "ou=people,o=acme.com,dc=ldapdev,dc=acme,dc=com";
        public static void main( String[] args )
            try
                Hashtable env = new Hashtable();
                env.put( Context.INITIAL_CONTEXT_FACTORY,
                    "com.sun.jndi.ldap.LdapCtxFactory");
                env.put( Context.PROVIDER_URL, "ldap://1.2.3.4:389");
                env.put( Context.SECURITY_AUTHENTICATION, "simple" );
                env.put( Context.SECURITY_PRINCIPAL, "uid=admin," + s_PrincipalRoot );
                env.put( Context.SECURITY_CREDENTIALS, "admin");
                // Create the initial context
                DirContext ctx = new InitialDirContext(env);
                   // Create the sub context
                ctx.addToEnvironment( Context.SECURITY_CREDENTIALS, "password" );
                String userP = "uid=dmb," + s_PrincipalRoot;
                DirContext subCtx = (DirContext) ctx.createSubcontext( userP );
                   Attributes atts = subCtx.getAttributes( userP );
                   Attribute att = atts.get( "uid" );
                   String value = (String) att.get();
                   System.out.println( "UserID = " + value );
            catch (Exception e)
                e.printStackTrace();
    }

  • Thread safe servlets

    I have a question regarding the semantice of servlets. Consider you are calling a method
    public StringmodifyAddress(){......}in the service method of the servlet. Now considering that a servlet could be sericing multiple requests would this method be technically thread safe? If not what could we do to make it safe.
    cheers

    Ok let me rephrase and provide a little more details. Sorry I messed up the question the first time
    private String email;
    public void doPost(HttpServletRequest req, HttpServletResponse resp)
        throws ServletException, IOException
       User user = new User;
       String address =  user.modifyAddress(email);
    }Now in the class User
    public String modifyAddress(String email)
      //writes the email address to a database
    }Now I feel since user is a variable local to the service method it is thread safe, but a coworker feels that since email is a member variable it would not be thread safe. Please advise it seems that he might be correct.

  • Problem with JNDI/LDAP AND connection pool

    I'm a newbie to Java but am attempting to write a servlet that retrieves info use to populate the contents of drop down menus. I'd like to only have to do this once. The servlet also retrieves other data (e.g. user profile info, etc ...). I'd like to be able to use the connection pool for all of these operations but I'm getting a compile error:
    public class WhitePages extends HttpServlet {
    ResourceBundle rb = ResourceBundle.getBundle("LocalStrings");
    public static String m_servletPath = null;
    public static String cattrs = null;
    public static String guidesearchlist[] = {};
    public static int isLocalAddr = 0;
    private int aeCtr;
    private String[] sgDNArray;
    private HashMap sgDN2DNLabel = new HashMap();
    private HashMap sgDN2SearchGuide = new HashMap();
    private String strport;
    private int ldapport;
    private String ldaphost;
    private String ldapbinddn;
    private String ldapbindpw;
    private String ldapbasedn;
    private int maxsearchcontainers;
    private int maxsearchkeys;
    private String guidesearchbases;
    private String guidecontainerclass;
    private String strlocaladdr;
    private String providerurl;
    // my init method establishes the connection
    // pool and then retrieve menu data
    public void init(ServletConfig config) throws ServletException {
    super.init(config);
    String strport = config.getInitParameter("ldapport");
    ldapport = Integer.parseInt(strport);
    String strconts = config.getInitParameter("maxsearchcontainers");
    maxsearchcontainers = Integer.parseInt(strconts);
    String strkeys = config.getInitParameter("maxsearchkeys");
    maxsearchkeys = Integer.parseInt(strkeys);
    ldaphost = config.getInitParameter("ldaphost");
    ldapbinddn = config.getInitParameter("ldapbinddn");
    ldapbindpw = config.getInitParameter("ldapbindpw");
    ldapbasedn = config.getInitParameter("ldapbasedn");
    guidesearchbases = config.getInitParameter("guidesearchbases");
    guidecontainerclass = config.getInitParameter("guidecontainerclass");
    strlocaladdr = config.getInitParameter("localaddrs");
    providerurl = "ldap://" + ldaphost + ":" + ldapport;
    /* Set up environment for creating initial context */
    Hashtable env = new Hashtable(11);
    env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
    env.put(Context.PROVIDER_URL, providerurl.toString());
    /* Enable connection pooling */
    env.put("com.sun.jndi.ldap.connect.pool", "true");
    StringTokenizer st = new StringTokenizer(guidesearchbases, ":" );
    String guidesearchlist[] = new String[st.countTokens()];
    for ( int i = 0; i < guidesearchlist.length; i++ ) {
    guidesearchlist[i] = st.nextToken();
    // Get a connection from the connection pool
    // and retrieve the searchguides
    StringBuffer asm = new StringBuffer(""); // This is the advanced search menu htmlobject buffer
    StringBuffer strtmpbuf = new StringBuffer(""); // This is the simple search menu htmlobject buffer
    try {
    StringBuffer filter = new StringBuffer("");
    filter.append("(objectclass=" + guidecontainerclass + ")");
    String[] attrList = {"dn","cn","searchguide"};
    SearchControls ctls = new SearchControls();
    ctls.setReturningAttributes(attrList);
    ctls.setSearchScope(SearchControls.SUBTREE_SCOPE);
    String attrlabelkey;
    sgDNArray = new String[guidesearchlist.length];
    for( int i = 0; i < guidesearchlist.length; i++ ) {
    // Search each of the namingspaces where
    // searchguides exist then build
    // the dynamic menus from the result
    DirContext ctx = new InitialDirContext(env);
    NamingEnumeration results = ctx.search(guidesearchlist, filter, ctls);
    I get a compile error:
    WhitePages.java:164: cannot resolve symbol
    symbol : method search (java.lang.String,java.lang.StringBuffer,javax.naming.directory.SearchControls)
    location: interface javax.naming.directory.DirContext
    NamingEnumeration results = ctx.search(guidesearchlist[i], filter, ctls);
    ^
    WhitePages.java:225: cannot resolve symbol
    symbol : variable ctx
    location: class OpenDirectory
    ctx.close();
    ^
    Can anyone help? If there is someone out there with JNDI connection pool experience I would appreciate your assistance!

    Manish
    The issue may not be related to the number of connections or the initial
    connections. Check your heap size (ms, mx). Turn on verbosegc. Your heap may
    not be big enough to accept the 25,000 rows.
    Bernie
    "Manish Kumar Singh" <[email protected]> wrote in message
    news:3e6c34ca$[email protected]..
    We are creating the result set with 25000 rows(each row has 56 columns) bygetting the connection using data source. With the initial capacity of the
    connection pool is 5 and the max capacity as 30 and grow connection as 1,
    the server gets out of memory exception, when we issue a new request, even
    after closing the previous connections.
    Now, if we change the initial capacity to 1 and rest all the things assame, the issue gets resolved and the server works fine.
    Could you please help me out in this regard????
    thanks in advance
    manish

  • Are static nested classes thread-safe?

    There doesn't seem to be any definitive answer to this. Given the following code, is it thread-safe?
    public class SomeMultiThreadedWebController {
    public HttpServletResponse someMethodToExecuteViaWebRequest(HttpServletRequest request) {
        simpleQueryBuilder("SELECT...").addParameter("asdf","asdf").createQuery(EMF.getEntityManager()).executeUpdate();
    protected static class SimpleQueryBuilder {
             private String queryString;
             private Map<String, Object> params = new HashMap<String, Object>();
             public SimpleQueryBuilder(String queryString) {
                  this.queryString = queryString;
             public SimpleQueryBuilder addParameter(String name, Object value) {
                  params.put(name, value);
                  return this;
             public Query createQuery(EntityManager em) {
                  Query query = em.createQuery(queryString);
                  for (Entry<String, Object> entry : params.entrySet()) {
                       query.setParameter(entry.getKey(), entry.getValue());
                  return query;
        public static SimpleQueryBuilder simpleQueryBuilder(String queryString) {
             return new SimpleQueryBuilder(queryString);
    }Forget whether or not someone would do this, as this is just an example. I'm really trying to get at whether or not the instance variables inside the static nested class are thread-safe. Thanks for any responses.

    Hello,
    I believe you understand what you're talking about, but you state it in a way that is very confusing for others.
    Let me correct this (essentially, incorrect uses of the terminology):
    I agree that thread-safe or not is for an operation, for a member, it has some sort of contextual confusion.
    Member has a much broader meaning in the [Java Language Specification|http://java.sun.com/docs/books/jls/third_edition/html/names.html#6.4] . Even "class member" applies to both an attribute, a method, or an inner class or interface.
    I think you mean "member variable" of a class (aka "attribute" or "field"). By the way, static or not is irrelevant to the rest of the discussion.
    For an operation or a member, if there's only one thread could access it atomically in one moment, we could call it thread-safe.Mmm. I was tempted to say yes (I'm reluctant to commit myself). With an emphasis on "_The encapsulating class_ makes this member's usage thread-safe".
    Still, just synchronizing each operation on a member is not enough to make all usages "thread-safe":
    Consider a java.util.Vector: each add/get is synchronized, so it is atomic, fine.
    However if one thread adds several values, let's say 3, one by one, to a vector that initially contains 0 values, and another thread reads the vector's size() (another properly synchronized method), the reader thread may witness a size anywhere among 0, 1, 2, 3, which, depending on the business logic, may be a severely inconsistent state.
    The client code would have to make extra work (e.g. synchronizing on the vector's reference before the 3 adds) to guarantee that the usage is thread-safe.
    Thus any synchronized method(With the limit stated above)
    or immutable member (like primitive type) are thread-safe.
    Additionally for a member, if it's immutable, then it's thread-safe. You mean, immutable primitive type, or immutable object. As stated previously, an immutable reference to a mutable object isn't thread-safe.
    a static final HashMap still have thread-safe issue in practice because it's not a primitive.The underlined part is incorrect. A primitive may have thread-safety issues (unless it's immutable), and an object may not have such issues, depending on a number of factors.
    The put, get methods, which will be invoked probably, are not thread-safe although the reference to map is.Yes. And even if the put/get methods were synchronized, the client code could see consistency issues in a concurrent scenario, as demonstrated above.
    Additional considerations:
    1) read/write of primitive types are not necessarily atomic: section [ §17.7 of the JLS|http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.7] explicitly states that writing a long or double value (2 32-bits words) may not be atomic, and may be subject to consistency issues in a concurrent scenario.
    2) The Java Memory Model explicitly allows non-synchronized operations on non-volatile fields to be implemented in a "thread-unsafe" way by the JVM. Leading way to a lot of unintuitive problems such as the "Double-Checked Locking idiom is broken". Don't make clever guess on code execution path unless you properly synchronize access to variables across threads.
    Edited by: jduprez on Mar 4, 2010 9:53 AM

Maybe you are looking for