Distributed Queue/JMX - JNDI lookup on startup fails

Hi,
I have a problem starting up Camel routes on a cluster via JMX. Although I have a NotificationListener registered that tries to startup the routes when the server sends a STATE=RUNNING lifecycle event, I cannot start the all Camel routes due to a "JMSException, Destination not found".
But, when I remote debug the application and put a breakpoint in, wait let's say 5 secs, then the JNDI lookup works and everything is fine.
I have unsuccessfully tried to play with the deployment order or my ear (by default the JMSServer is started with a priority of 1000), no luck. I have also put a poll method in, that waits until the JMSServer and the Destinations (=queues) are available, again no luck.
Anyone able to assist with that issue?
Best Regards,
Sebastian

I found the reason for the late binding. We are using "migratable target" in our cluster. When I remove the migratable target I have no issue whatsoever. Is there a way to either tweak the config or configure the Migratable targets in a way to by-pass this issue?
Regards,
Seb

Similar Messages

  • JNDI Lookup in JSP fails for EJB 3.0

    I am new to Java technology. I read the EJB FAQ, NetBeans docs and may forum discussions and I am still confused with the error I am having.
    Background:
    I have developed a persistance bean and related sessions beans (similar to the customer-cmp-ear application in the Java App Server samples). Now I am trying to access this bean using a JSP. After deploying the war file in the App Server and try to access the page, I get the following error.
    javax.naming.NameNotFoundException: No object bound to name java:comp/env/ConsumerSessionLocal
    After reading many articles, I understood that I dont have to prepare any descriptors, or JAR files for EJB 3.0.
    Environment Details:
    Java App Server Ver 9.0
    NetBeans 5.5
    I normally build the war files using NetBeans.
    I use App Server Admin console to deploy the web applications using the above war file.
    EJB details:
    Persistance EJB : person.java
    Session Objects
    Consumer.java (this implements ConsumerSessionLocal, ConsumerSessionRemote). This Stateless bean accesses the methods in person.java.
    ConsumerSessionLocal.java - local interface
    ConsumerSessionRemote.java - remote interface
    SearchConsumer.jsp
    This JSP page is calling the ConsumerSessionLocal using the JNDI lookup through InitialContext.
    Here is the Code snippet:
    try {
    InitialContext ic = new InitialContext();
    Object o = ic.lookup("java:comp/env/ConsumerSessionLocal");
    ConsumerSessionLocal consSession = (ConsumerSessionLocal) o;
    I am able to see the jsp page in the browser, however, after a submit action, I get the Java Naming Exception error.
    javax.naming.NameNotFoundException: No object bound for java:comp/env/ConsumerSessionLocal
    I would appreciate your help/any of your thoughts.
    Thanks in advance.
    -Ram

    I did not really solve it. Instead I used some of the tutorials that used JNDI lookup and modified those as my way forward. I did not really find out exactly what I was doing wrong.
    /Anders

  • JNDI Lookup of ConnectionFactory fails from inside Glassfish application

    This may very well end up being a glassfish specific question.
    I've got a stand-alone WAR using JSF, where I have a backing bean use some helper objects that will send a JMS message. When this WAR is running from inside of Glassfish, it fails to do the lookup of the ConnectionFactory.
    The application pulls the Queue JNDI and the Provider URL from a database, and uses a env Hashtable to do the JNDI InitialContext (which succeeds.) Using this Context, the ConnectionFactory lookup fails.
    The remote server in this instance is WebLogic 9.2 (the JNDI is publically available with no user authentication, verified with a JMS developer tool we use internally.)
    Here's the stacktrace...
    2007-10-15 19:48:04,514 ERROR [net.acadiasoft.shared.jms.util.JMSSenderHelper:130] NamingException: messageFactory not found
    javax.naming.NameNotFoundException: messageFactory not found
    at com.sun.enterprise.naming.TransientContext.doLookup(TransientContext.java:216)
    at com.sun.enterprise.naming.TransientContext.lookup(TransientContext.java:188)
    at com.sun.enterprise.naming.SerialContextProviderImpl.lookup(SerialContextProviderImpl.java:74)
    at com.sun.enterprise.naming.LocalSerialContextProviderImpl.lookup(LocalSerialContextProviderImpl.java:111)
    at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:339)
    at javax.naming.InitialContext.lookup(InitialContext.java:351)
    at net.acadiasoft.shared.jms.util.JMSSenderHelper.getConnectionFactory(JMSSenderHelper.java:128)
    at net.acadiasoft.shared.jms.util.JMSSenderHelper.init(JMSSenderHelper.java:58)
    at net.acadiasoft.shared.jms.util.JMSSenderHelper.<init>(JMSSenderHelper.java:36)
    at net.acadiasoft.web.shared.jms.util.AdminJmsHelper.<init>(AdminJmsHelper.java:19)
    at net.acadiasoft.web.server.pages.SchedulerBackingBean.deleteJobs(SchedulerBackingBean.java:75)

    I've found the problem, and it's something I simply overlooked. I don't know why I didnt realize, but i was setting the java.naming.factory.initial env variable to what Glassfish uses, not WebLogic.

  • JNDI lookup of DataSource fails

    I'm trying to create a DataSource as follows:
    Connection connection = null;
    String ACCOUNT_DATASOURCE = "weblogic.jdbc.AccountDB";
    try {
    Context ctx = new InitialContext(System.getProperties());
    DataSource ds = (DataSource)ctx.lookup(ACCOUNT_DATASOURCE);
    connection = ds.getConnection();
    catch (Exception e) {
    The client window reveals:
    javax.ejb.CreateException: java.lang.NullPointerException
    at weblogic.rmi.internal.BasicOutboundRequest.sendReceive(BasicOutboundR
    equest.java:85)
    at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteR
    ef.java:274)
    at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteR
    ef.java:243)
    at weblogic.rmi.internal.ProxyStub.invoke(ProxyStub.java:90)
    at $Proxy1.create(Unknown Source)
    at helloWorld.Client.main(Client.java:22)
    Destroying account..
    The server window reveals:
    javax.naming.NameNotFoundException: Unable to resolve weblogic.jdbc.AccountDB.
    R
    esolved: 'weblogic.jdbc' Unresolved:'AccountDB' ; remaining name ''
    <<no stack trace available>>
    Via the console GUI I created a connection pool, which frequently disappears -
    I do not understand at all why this pool seems so transient but it doesn't sound
    good, and a data source, which does seem to persist, whose JNDI name corresponds
    exactly to the name used for the lookup above. I've seen some usage of the form
    java:comp/env/jdbc/... is this simply an arbitrary and therefore optional prefix,
    or does it have some arcance meaning of which I am unaware?
    Finally, the weblogic-ejb-jar.xml file defines the BMP entity bean and its associated
    JNDI name for the database connection.
    I've also created the cloudscape database via a .ddl file and copied it across
    to the ~/wlserver6.1_beta/samples/eval/cloudscape/data directory (this might not
    be the correct place)
    Any ideas or suggestions most welcome - I've currently come to a grinding halt
    with this.

    Did you make sure the DataSource (and the underlying connection pool were
    actually "deployed" to a target server after you created them? That bit me
    for a while...
    If you open up the console and open up the "Servers" folder on the left and
    right click on your server (myserver) and select "View JNDI Tree", do you
    see your DataSource under the jdbc node?
    greg
    "David Franklin" <[email protected]> wrote in message
    news:[email protected]...
    >
    I'm trying to create a DataSource as follows:
    Connection connection = null;
    String ACCOUNT_DATASOURCE = "weblogic.jdbc.AccountDB";
    try {
    Context ctx = new InitialContext(System.getProperties());
    DataSource ds = (DataSource)ctx.lookup(ACCOUNT_DATASOURCE);
    connection = ds.getConnection();
    catch (Exception e) {
    The client window reveals:
    javax.ejb.CreateException: java.lang.NullPointerException
    atweblogic.rmi.internal.BasicOutboundRequest.sendReceive(BasicOutboundR
    equest.java:85)
    atweblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteR
    ef.java:274)
    atweblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteR
    ef.java:243)
    at weblogic.rmi.internal.ProxyStub.invoke(ProxyStub.java:90)
    at $Proxy1.create(Unknown Source)
    at helloWorld.Client.main(Client.java:22)
    Destroying account..
    The server window reveals:
    javax.naming.NameNotFoundException: Unable to resolveweblogic.jdbc.AccountDB.
    R
    esolved: 'weblogic.jdbc' Unresolved:'AccountDB' ; remaining name ''
    <<no stack trace available>>
    Via the console GUI I created a connection pool, which frequentlydisappears -
    I do not understand at all why this pool seems so transient but it doesn'tsound
    good, and a data source, which does seem to persist, whose JNDI namecorresponds
    exactly to the name used for the lookup above. I've seen some usage ofthe form
    java:comp/env/jdbc/... is this simply an arbitrary and therefore optionalprefix,
    or does it have some arcance meaning of which I am unaware?
    Finally, the weblogic-ejb-jar.xml file defines the BMP entity bean and itsassociated
    JNDI name for the database connection.
    I've also created the cloudscape database via a .ddl file and copied itacross
    to the ~/wlserver6.1_beta/samples/eval/cloudscape/data directory (thismight not
    be the correct place)
    Any ideas or suggestions most welcome - I've currently come to a grindinghalt
    with this.

  • JNDI Lookup of EJB fails

    Hello,
    I have installed JDeveloper 9.0.3 on windows. I created a workspace and sample project for testing. Added a CMP EJB (Dept) using JDevs "create EJB from table option", added a client to test the EJB using JDevs 'New Sample Client" option, compiled the project and ran the sample client. I get the following error in the embedded OC4J
    javax.naming.NameNotFoundException: Dept not found
         java.lang.Object com.evermind.server.rmi.RMIContext.lookup(java.lang.String)
    I have not changed any bit of configuration and code generated by JDev.
    I tried this because I was getting the same error in a working project imported from other machine.
    Any solution?
    Thanks in advance.
    NAG

    First you need to run the EJB and then run the client.
    Here is something to guide you:
    http://otn.oracle.com/products/jdev/htdocs/handson/j2ee/j2ee13hos.html#lab2
    By the way, why are you using such an old version of JDeveloper? Isn't it time to upgrade to 9.0.5 or at least 9.0.4?

  • Distributed Queues - wls6.1sp4 : queue lookup syntax

              Hello,
              I've implemented the distributed queue approximation design pattern, with a cluster
              of 2 wls61sp4 instances.
              It suggests I have to locate the queue using the syntax :
              javax.jms.QueueSession.createQueue("./<queueName>")
              Is this compulsary ?
              If I use the standard syntax :
              (Queue) context.lookup("<jndiQueueName>")
              (with context = new InitialContext())
              what wrong can happen ?
              It looks like I always go "locally", on the queue on the same wls (and not to
              a remote destination), with both syntaxes.
              So I don't understand why I have to use the non createQueue("./<queueName>") syntax
              in this pattern.
              Thanks in advance
              Best regards
              Mark Cordobal
              

              Mark Cordobal wrote:
              > Thanks.
              > Now it's clear.
              >
              > But it happens I'm using a non-transactional MDB (targetted to a 6.1sp4 cluster,
              > with a "distributed" queue, following the approximation pattern).
              >
              > And you've said that there is a bug...
              >
              > My doubt now is :
              >
              > what can happen at runtime if the MDB fails to ack a received message ?
              >
              > The unique problem I can see is that I could have some "pending" bytes on the
              > monitoring page of the wl console, isn't it ?
              >
              > Or could I have any other problems (from my application point of view) ?
              Because the messages aren't ack'd, they do not get deleted, continue
              to consume memory, and the persistent ones come back on the next reboot.
              There is a patch (contact customer support). Alternatively, upgrade
              to SP5.
              >
              > Thanks in advance
              >
              > Best Regards
              >
              > Mark
              >
              >
              >
              >
              > SP4 has a bug in non-transactional MDBs which SP5 fixes,
              >
              >>the MDBs fail to ack received messages
              >
              >
              >
              >
              > Tom Barnes <[email protected]> wrote:
              >
              >>
              >>Mark Cordobal wrote:
              >>
              >>>Thanks Tom.
              >>>
              >>>In my case my jms client is an ejb (ssb).
              >>>
              >>>If I use new InitialContext(), I should receive (with a lookup) a
              >>
              >>"local" (where
              >>
              >>>there is the ejb) JMS Connection Factory, and this Connection Factory
              >>
              >>should "give"
              >>
              >>>to me a connection to the "local" JMS Server, isn't it ?
              >>
              >>Yes.
              >>
              >>
              >>>The same should happen with the queue : if I use new InitialContext(),
              >>
              >>and look
              >>
              >>>up the queue, I should receive a "local" queue (where there is my ejb).
              >>
              >>Yes. (You are setting JNDINameReplicated on each queue to false,
              >>I assume, to allow multiple deployments of the same queue.)
              >>
              >>
              >>>So, am I wrong if I say that it's useful to use that syntax (createQueue("./<queueName>"))
              >>>only if I'm an "external" jms client (not an ejb, but, for example,
              >>
              >>an external
              >>
              >>>java application) ?
              >>
              >>You are not wrong.
              >>
              >>
              >>>And that I can use indifferently both syntaxes if I have an ejb obtaining
              >>
              >>always
              >>
              >>>the same effect ("local execution" guaranteed) ?
              >>
              >>Yep.
              >>
              >>BTW, FYI - SP4 has a bug in non-transactional MDBs which SP5 fixes,
              >>the MDBs fail to ack received messages.
              >>
              >>
              >>>Thanks in advance
              >>>
              >>>Best regards
              >>>
              >>>
              >>>Mark
              >>>
              >>>
              >>>Tom Barnes <[email protected]> wrote:
              >>>
              >>>
              >>>>Hi Mark,
              >>>>
              >>>>The JMS connection factory load balances the connections
              >>>>it creates across all server's it is targeted at. This
              >>>>means that the JNDI connection and JMS connection can
              >>>>end up on different WL servers. Consequently, the JNDI
              >>>>lookup can yield a queue local to the server JNDI is
              >>>>hooked up to rather than local to the server the JMS
              >>>>client is hooked up to. If this occurs, the JMS
              >>>>client send/receive requests will end up routing from the JMS
              >>>>connection's host server to the server that actually
              >>>>hosts the queue - a performance hit which may not matter
              >>>>in your case. The next version of the white-paper
              >>>>will include this info.
              >>>>
              >>>>Tom
              >>>>
              >>>>Mark Cordobal wrote:
              >>>>
              >>>>
              >>>>>Hello,
              >>>>>
              >>>>>I've implemented the distributed queue approximation design pattern,
              >>>>
              >>>>with a cluster
              >>>>
              >>>>
              >>>>>of 2 wls61sp4 instances.
              >>>>>
              >>>>>It suggests I have to locate the queue using the syntax :
              >>>>>
              >>>>>javax.jms.QueueSession.createQueue("./<queueName>")
              >>>>>
              >>>>>Is this compulsary ?
              >>>>>
              >>>>>If I use the standard syntax :
              >>>>>
              >>>>>(Queue) context.lookup("<jndiQueueName>")
              >>>>>
              >>>>>(with context = new InitialContext())
              >>>>>
              >>>>>what wrong can happen ?
              >>>>>
              >>>>>It looks like I always go "locally", on the queue on the same wls
              >>>>
              >>(and
              >>
              >>>>not to
              >>>>
              >>>>
              >>>>>a remote destination), with both syntaxes.
              >>>>>
              >>>>>So I don't understand why I have to use the non createQueue("./<queueName>")
              >>>>
              >>>>syntax
              >>>>
              >>>>
              >>>>>in this pattern.
              >>>>>
              >>>>>
              >>>>>Thanks in advance
              >>>>>
              >>>>>Best regards
              >>>>>
              >>>>>Mark Cordobal
              >>>>
              >
              

  • JMS Wrappers can't cache JNDI lookups when using secured queues

    Hi All!
    We are working on a jms client, inside a webapp(servlets), using Weblogic 9.2 and Weblogic 10.3.
    As we want to use secured queues and keep being efficient we tryed to use Weblogic JMS Wrappers, that should work according to the docs:
    Enhanced Support for Using WebLogic JMS with EJBs and Servlets
    http://download.oracle.com/docs/cd/E12840_01/wls/docs103/jms/j2ee.html
    But we are facing a problem:
    When we define a JMS Wrapper and try to cache JNDI lookups for the QueueConnectionFactory and Queue, as the docs recommend for efficiency, the connection to the queue is ignoring the user/pwd.
    The JMS Wrapper is using <res-auth>Application</res-auth>.
    We are creating the connection using createQueueConnection(user, pwd) from QueueConnectionFactory and after several tests it seems that the user and password are ingored unless a jndi lookup is made in the same thread, as if when there are not any thread credentials present user and password are ignored for the connection...
    so the question is:
    That behaviour goes against Weblogic JMS Wrapper documentation, doesn't it?
    Is there then any other way to access efficiently secured queues using a servlet as a client? (iit's not an option for us to use mdbs, or ejbs).
    If it helps, this seems related to this still opened spring-weblogic issue: SPR-2941 --> http://jira.springframework.org/browse/SPR-2941 and SPR-4720 --> http://jira.springframework.org/browse/SPR-4720
    Thanxs
    And here goes our DDs and code to reproduce:
    First in pretty format:
    web.xml --> http://pastebin.com/f5f85e8d4
    weblogic.xml --> http://pastebin.com/f2fbe10cc
    Client code --> http://pastebin.com/f586d32d9
    And now emmebded in the msg:
    web.xml
    <?xml version="1.0" encoding="UTF-8"?>
    <weblogic-web-app
      xmlns="http://www.bea.com/ns/weblogic/90"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://www.bea.com/ns/weblogic/90
      http://www.bea.com/ns/weblogic/90/weblogic-web-app.xsd">
        <description>WebLogic Descriptor</description>
        <resource-description>
            <res-ref-name>jms/QCF</res-ref-name>
            <jndi-name>weblogic.jms.ConnectionFactory</jndi-name>
        </resource-description>
    </weblogic-web-app>weblogic.xml
    <?xml version="1.0" encoding="UTF-8"?>
    <web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
          <display-name> QCFWrapperCredentialsTest </display-name>
          <description> QCFWrapperCredentialsTest  </description>
          <servlet id="Servlet_1">
             <servlet-name>QCFWrapperCredentialsTest</servlet-name>
             <servlet-class>QCFWrapperCredentialsTest</servlet-class>
             <load-on-startup>1</load-on-startup>
          </servlet>
          <servlet-mapping id="ServletMapping_1">
             <servlet-name>QCFWrapperCredentialsTest</servlet-name>
             <url-pattern>/Test</url-pattern>
          </servlet-mapping>
         <resource-ref>
            <res-ref-name>jms/QCF</res-ref-name>
            <res-type>javax.jms.QueueConnectionFactory</res-type>
            <res-auth>Application</res-auth>
            <res-sharing-scope>Shareable</res-sharing-scope>
        </resource-ref>
    </web-app>And our test client:
    import java.io.*;
    import java.util.Properties;
    import javax.jms.*;
    import javax.naming.*;
    import javax.servlet.http.*;
    public class QCFWrapperCredentialsTest extends HttpServlet {
        QueueConnectionFactory factory = null;
        Queue queue = null;
        String jndiName = "java:comp/env/jms/QCF";
        String queueName= "jms/ColaEntradaConsultas";
        String user = "usuarioColas";
        String pwd = "12345678";
        String userjndi = "usuarioColas";
        String pwdjndi = "12345678";
        String serverT3URL="t3://127.0.0.1:7007";
        public void init() {
            setupJNDIResources();
        private void setupJNDIResources(){
            try {
                Properties props = new Properties();
                props.put("java.naming.factory.initial",
                        "weblogic.jndi.WLInitialContextFactory");
                props.put("java.naming.provider.url",serverT3URL );
                props.put("java.naming.security.principal", userjndi);// usr
                props.put("java.naming.security.credentials", pwdjndi);// pwd
                InitialContext ic = new InitialContext(props);
                factory = (QueueConnectionFactory) ic.lookup(jndiName);
                queue = (Queue) ic.lookup(queueName);
            } catch (NamingException e) {
                e.printStackTrace();
        public void service(HttpServletRequest req, HttpServletResponse res) {
            res.setContentType("text/html");
            Writer wr = null;
            try {
                wr = res.getWriter();
                //Comment this out, do a lookup for each request and it will work
                //setupJNDIResources();
                String user = this.user;
                String pwd = this.pwd;
                //read users and passwords from the request in case they are present
                if (req.getParameter("user") != null) {
                    user = req.getParameter("user");
                if (req.getParameter("pwd") != null) {
                    pwd = req.getParameter("pwd");
                wr.write("JNDI  User: *" + userjndi + "* y pwd: *" + pwdjndi + "*<p>");
                wr.write("Queue User: *" + user + "* y pwd: *" + pwd + "*<p>");
                //Obtain a connection using user/pwd
                QueueConnection conn = factory.createQueueConnection(user, pwd);
                QueueSession ses = conn.createQueueSession(true,
                        Session.SESSION_TRANSACTED);
                QueueSender sender = ses.createSender(queue);
                TextMessage msg = ses.createTextMessage();
                msg.setText("Hi there!");
                conn.start();
                sender.send(msg);
                ses.commit();
                sender.close();
                ses.close();
                conn.close();
            } catch (Exception e) {
                e.printStackTrace();
                try {
                    wr.write(e.toString());
                } catch (Exception e2) {
                    e2.printStackTrace();
            finally{
                try {
                    wr.close();
                } catch (IOException e) {
                    e.printStackTrace();
    }Edited by: user2525402 on Feb 9, 2010 7:14 PM

    Thanks Tom,
    Quite a useful response .-)
    Leaving aside the fact that weblogic behaviour with jms wrappers and secured queues seems to not be working as the docs says...
    Talking about workarounds:
    Both workarounds you suggest works, but as you already noted, creating a new JNDI context just to inject credentials into the threads is overkill when high performance is needed.
    I also found more information about the same issue here: http://sleeplessinslc.blogspot.com/2009/04/weblogic-jms-standalone-multi-threaded.html
    And he suggest the same workaround, injecting credentials
    So I tried the second approach, successfully, injecting credentials into the thread using the security API.
    This way, using JMS wrappers and injecting credentials into the thread we get the best performance available, caching resource using wrappers and using credentials in a somewhat efficient way.
    Now the test snippet looks like this:
    import java.io.*;
    import java.security.PrivilegedAction;
    import java.util.Properties;
    import javax.jms.*;
    import javax.naming.*;
    import javax.security.auth.Subject;
    import javax.security.auth.login.LoginException;
    import javax.servlet.http.*;
    import weblogic.jndi.Environment;
    import weblogic.security.auth.Authenticate;
    public class JMSWrapperCredentialsTest extends HttpServlet {
        QueueConnectionFactory factory = null;
        Queue queue = null;
        String jndiName = "java:comp/env/jms/QCF";
        String queueName= "jms/ColaEntradaConsultas";
        String user = "usuarioColas";
        String pwd = "12345678";
        String userjndi = "usuarioColas";
        String pwdjndi = "12345678";
        String serverT3URL="t3://127.0.0.1:7007";
        public void init() {
            setupJNDIResources();
        private void setupJNDIResources(){
            try {
                Properties props = new Properties();
                props.put("java.naming.factory.initial",
                        "weblogic.jndi.WLInitialContextFactory");
                props.put("java.naming.provider.url",serverT3URL );
                props.put("java.naming.security.principal", userjndi);// usr
                props.put("java.naming.security.credentials", pwdjndi);// pwd
                InitialContext ic = new InitialContext(props);
                factory = (QueueConnectionFactory) ic.lookup(jndiName);
                queue = (Queue) ic.lookup(queueName);
            } catch (NamingException e) {
                e.printStackTrace();
        public void service(HttpServletRequest req, HttpServletResponse res) {
            final HttpServletRequest fReq=req;
            final HttpServletResponse fRes=res;
            PrivilegedAction action = new java.security.PrivilegedAction() {
                public java.lang.Object run() {
                    performRequest(fReq,fRes);
                    return null;
            try {
                Subject subject=createSingleSubject(serverT3URL,user,pwd);
                weblogic.security.Security.runAs(subject, action);
            } catch (Exception e) {
                e.printStackTrace();
        public void performRequest(HttpServletRequest req, HttpServletResponse res) {
            res.setContentType("text/html");
            Writer wr = null;
            try {
                wr = res.getWriter();
                //Comment this out, do a lookup for each request and it will work
                //setupJNDIResources();
                String user = this.user;
                String pwd = this.pwd;
                //read users and passwords from the request in case they are present
                if (req.getParameter("user") != null) {
                    user = req.getParameter("user");
                if (req.getParameter("pwd") != null) {
                    pwd = req.getParameter("pwd");
                wr.write("JNDI  User: *" + userjndi + "* y pwd: *" + pwdjndi + "*<p>");
                wr.write("Queue User: *" + user + "* y pwd: *" + pwd + "*<p>");
                //Obtain a connection using user/pwd
                QueueConnection conn = factory.createQueueConnection(user, pwd);
                QueueSession ses = conn.createQueueSession(true,
                        Session.SESSION_TRANSACTED);
                QueueSender sender = ses.createSender(queue);
                TextMessage msg = ses.createTextMessage();
                msg.setText("Hi there!");
                conn.start();
                sender.send(msg);
                ses.commit();
                sender.close();
                ses.close();
                conn.close();
            } catch (Exception e) {
                e.printStackTrace();
                try {
                    wr.write(e.toString());
                } catch (Exception e2) {
                    e2.printStackTrace();
            finally{
                try {
                    wr.close();
                } catch (IOException e) {
                    e.printStackTrace();
        private Subject createSingleSubject(String providerUrl, String userName, String password) {
            Subject subject = new Subject();
            // Weblogic env class
            Environment env = new Environment();
            if(providerUrl!=null)
                env.setProviderUrl(providerUrl);
            env.setSecurityPrincipal(userName);
            env.setSecurityCredentials(password);
            try {
              // Weblogic Authenticate class will populate and Seal the subject
              Authenticate.authenticate(env, subject);
              return subject;
            catch (LoginException e) {
              throw new RuntimeException("Unable to Authenticate User", e);
            catch (Exception e) {
              throw new RuntimeException("Error authenticating user", e);
    }Thanks a lot for the help

  • WLS/OSB DB Adapter - JNDI lookup failed

    Hello all.
    I've got a DB adapter service set up in a clustered environment, and it all works (and I've built proxy services, transformations etc around it), but I've just noticed that the log shows a warning regarding the JNDI lookup of the ConnectionFactory, as below.
    It's working, and the error is only a warning, but could this cause problems going forward, particularly with regards performance?
    Given that the ConnectionFactory name is 'com.whatever.myServiceDB', and the Endpoint URI of the service is 'jca://com.whatever.myServiceDB', what could be wrong? Has anyone seen/fixed this before? It's almost like the managed servers don't know about the JNDI name...but the DbAdapter deployent has 'All servers in the cluster' selected in its 'Targets' tab, so I'm not sure.
    Any pointers would be appreciated, I'm probably missing something obvious.
    Cheers.
    ####<Apr 15, 2010 10:53:10 AM BST> <Warning> <JCA_FRAMEWORK_AND_ADAPTER> <servername> <managed3_domainname> <[ACTIVE] ExecuteThread: '4' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1271325190453> <BEA-000000> <servicebus:/WSDL/MyProject/MyService [ MyService_ptt::merge(MessagesCollection) ] - JNDI lookup of 'com.whatever.myServiceDB' failed due to: String index out of range: -1>

    Thanks again.
    In case anyone runs into a similar problem and is wondering: a bit of mucking about reveals that the WLS ConnectionFactory config is fine with dots or slashes, and it seems to treat both the same when creating the JNDI tree.
    However, the WSDL (that you probably created in JDeveloper) has to have slashes for doing its lookup. So, for example, always use slashes rather than dots when setting your DB Adapter JNDI name in JDeveloper. I guess this is a bit different from usual class/package naming standards, so may catch someone else out too.
    Cheers.

  • JNDI lookup fails - No such domain/application

    Hi,
    I tried to perform a JNDI lookup from a stand alone Java client towards Oracle 9iAS version 9.0.3 and failed with the following error:
    javax.naming.NamingException: Lookup error: javax.naming.AuthenticationException: No such domain/application: mindejb; nested exception is:
         javax.naming.AuthenticationException: No such domain/application: mindejb
         java.lang.Object com.evermind.server.rmi.RMIContext.lookup(java.lang.String)
              RMIContext.java:134
         java.lang.Object javax.naming.InitialContext.lookup(java.lang.String)
              InitialContext.java:345
         void Samplecom.mind.ejb.stubs.AccountComplexStubClient.main(java.lang.String[])
              AccountComplexStubClient.java:21
    Below, are the JNDI settings I am using. The application by the name mindejb was deployed and is accessible using server side JSP or servlets. When I use a stand alone OC4J, the same settings (different port) work fine!
    java.naming.factory.initial=com.evermind.server.rmi.RMIInitialContextFactory
    java.naming.provider.url=ormi://localhost:3101/mindejb
    java.naming.security.principal=admin
    java.naming.security.credentials=admin
    Thanks,
    Avi

    When you are running within an Oracle Application Server managed OC4J environment, then you should use the OPMN protocol loader we have that will insulate you from the specified ORMI port being used by OC4J.
    The OPMN port is fixed so you can always rely on it, whereas the specific ORMI port used by an OC4J instance changes depending on the startup sequence, the number of procs configured, etc.
    Here's a piece from the EJB documentation
    http://download-west.oracle.com/docs/cd/B14099_19/web.1012/b15505/access.htm#i1019709
    Location
    All ports, including the RMI port, are dynamically set by OPMN when each OC4J instance starts. When you specify the following URL in the client JNDI properties, the client-side OC4J retrieves the dynamic ports for the instance, and chooses one from the list for communication.
    java.naming.provider.url= opmn:ormi://<opmn_host>:<opmn_port>:<oc4j_instance>/<application-name>
    The OPMN host name and port number is retrieved from the opmn.xml file. In most cases, OPMN is located on the same machine as the OC4J instance. However, you must specify the host name in case it is located on another machine. The OPMN port number is optional; if excluded, the default is port 6003. The OPMN port is specified in opmn.xml.
    cheers
    -steve-

  • JNDI lookup fails in a thread created by J2EE application on WAS 8.0.0.4 running on Red Hat Enterprise Server 5.8(2.6.18-308.e15).

    I am using Jackrabbit Repository (jcr's implementation) as backend in my Web Appl.Whose data persists on Oracle Database. To make connection with Oracle database jackrabbit provide provision of JNDI Lookup to read the data source defined in WAS (using WAS 8.0.0.4 as App Server).
    I am able to perform JNDI Lookup everywhere in my application,But in a flow where i am creating a Thread using Java Concurrent Api and insidethread's call() method when I am trying for JNDI Look following exception occurs –
    [8/20/13 10:57:35:163 IST] 000000dd System Out     O ERROR 20-08 10:57:35,163 (DatabaseFileSystem.java:init:209)            failed to initialize file system
    javax.jcr.RepositoryException: JNDI name not found: java:comp/env/jdbc/ofsds
    at org.apache.jackrabbit.core.util.db.ConnectionFactory.getJndiDataSource(ConnectionFactory.java:295)
    at org.apache.jackrabbit.core.util.db.ConnectionFactory.createDataSource(ConnectionFactory.java:233)
    at org.apache.jackrabbit.core.util.db.ConnectionFactory.getDataSource(ConnectionFactory.java:166)
    at org.apache.jackrabbit.core.fs.db.DbFileSystem.getDataSource(DbFileSystem.java:226)
    at org.apache.jackrabbit.core.fs.db.DatabaseFileSystem.init(DatabaseFileSystem.java:190)
    at org.apache.jackrabbit.core.config.RepositoryConfigurationParser$6.getFileSystem(RepositoryConfigurationParser.java:1057)
    at org.apache.jackrabbit.core.config.RepositoryConfig.getFileSystem(RepositoryConfig.java:911)
    at org.apache.jackrabbit.core.RepositoryImpl.<init>(RepositoryImpl.java:285)
    at org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:605)
    at org.apache.jackrabbit.core.TransientRepository$2.getRepository(TransientRepository.java:232)
    at org.apache.jackrabbit.core.TransientRepository.startRepository(TransientRepository.java:280)
    at org.apache.jackrabbit.core.TransientRepository.login(TransientRepository.java:376)
    at com.mmpnc.icm.server.repository.RepositoryStartupService.newSession(RepositoryStartupService.java:408)
    at com.mmpnc.icm.server.repository.RepositoryStartupService.newSession(RepositoryStartupService.java:355)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
    at java.lang.reflect.Method.invoke(Method.java:611)
    at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
    at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31)
    at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
    at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28)
    at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
    at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
    at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
    at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
    at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166)
    at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102)
    at com.mmpnc.icm.server.repository.RepositoryStartupService_$$_javassist_1.newSession(RepositoryStartupService_$$_javassist_1.java)
    at com.mmpnc.icm.server.repository.ICMHouseKeepingSessionManager.create(ICMHouseKeepingSessionManager.java:37)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
    at java.lang.reflect.Method.invoke(Method.java:611)
    at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
    at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31)
    at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
    at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28)
    at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
    at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:77)
    at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
    at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
    at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
    at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
    at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166)
    at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102)
    at com.mmpnc.icm.server.repository.ICMHouseKeepingSessionManager_$$_javassist_8.create(ICMHouseKeepingSessionManager_$$_javassist_8.java)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
    at java.lang.reflect.Method.invoke(Method.java:611)
    at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
    at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:138)
    at org.jboss.seam.Component.callComponentMethod(Component.java:2171)
    at org.jboss.seam.Component.callCreateMethod(Component.java:2094)
    at org.jboss.seam.Component.newInstance(Component.java:2054)
    at org.jboss.seam.Component.getInstance(Component.java:1948)
    at org.jboss.seam.Component.getInstance(Component.java:1910)
    at org.jboss.seam.Component.getInstance(Component.java:1904)
    at org.jboss.seam.Component.getInstanceInAllNamespaces(Component.java:2271)
    at org.jboss.seam.Component.getValueToInject(Component.java:2223)
    at org.jboss.seam.Component.injectAttributes(Component.java:1663)
    at org.jboss.seam.Component.inject(Component.java:1481)
    at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:61)
    at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
    at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
    at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
    at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
    at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166)
    at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102)
    at com.mmpnc.icm.server.repository.ICMHouseKeepingRepository_$$_javassist_7.create(ICMHouseKeepingRepository_$$_javassist_7.java)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
    at java.lang.reflect.Method.invoke(Method.java:611)
    at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
    at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:138)
    at org.jboss.seam.Component.callComponentMethod(Component.java:2171)
    at org.jboss.seam.Component.callCreateMethod(Component.java:2094)
    at org.jboss.seam.Component.newInstance(Component.java:2054)
    at org.jboss.seam.Component.getInstance(Component.java:1948)
    at org.jboss.seam.Component.getInstance(Component.java:1910)
    at org.jboss.seam.Component.getInstance(Component.java:1904)
    at org.jboss.seam.Component.getInstanceInAllNamespaces(Component.java:2271)
    at org.jboss.seam.Component.getValueToInject(Component.java:2223)
    at org.jboss.seam.Component.injectAttributes(Component.java:1663)
    at org.jboss.seam.Component.inject(Component.java:1481)
    at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:61)
    at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
    at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
    at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
    at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
    at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166)
    at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102)
    at com.mmpnc.icm.server.repository.ICMHouseKeepingManager_$$_javassist_6.create(ICMHouseKeepingManager_$$_javassist_6.java)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
    at java.lang.reflect.Method.invoke(Method.java:611)
    at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
    at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:138)
    at org.jboss.seam.Component.callComponentMethod(Component.java:2171)
    at org.jboss.seam.Component.callCreateMethod(Component.java:2094)
    at org.jboss.seam.Component.newInstance(Component.java:2054)
    at org.jboss.seam.Component.getInstance(Component.java:1948)
    at org.jboss.seam.Component.getInstance(Component.java:1910)
    at org.jboss.seam.Component.getInstance(Component.java:1904)
    at org.jboss.seam.Component.getInstance(Component.java:1899)
    at com.mmpnc.icm.server.concurrent.PerformCloseTask.call(PerformCloseTask.java:136)
    at com.mmpnc.icm.server.concurrent.PerformCloseTask.call(PerformCloseTask.java:1)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:314)
    at java.util.concurrent.FutureTask.run(FutureTask.java:149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:897)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:919)
    at java.lang.Thread.run(Thread.java:770)
    Caused by:
    javax.naming.ConfigurationException: A JNDI operation on a "java:" name cannot be completed because the server runtime is not able to associate the operation's thread with any J2EE application component.  This condition can occur when the JNDI client using the "java:" name is not executed on the thread of a server application request.  Make sure that a J2EE application does not execute JNDI operations on "java:" names within static code blocks or in threads created by that J2EE application.  Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on "java:" names. [Root exception is javax.naming.NameNotFoundException: Name comp/env/jdbc not found in context "java:".]
    at com.ibm.ws.naming.java.javaURLContextImpl.throwExceptionIfDefaultJavaNS(javaURLContextImpl.java:522)
    at com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS(javaURLContextImpl.java:552)
    at com.ibm.ws.naming.java.javaURLContextImpl.lookupExt(javaURLContextImpl.java:481)
    at com.ibm.ws.naming.java.javaURLContextRoot.lookupExt(javaURLContextRoot.java:485)
    at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:370)
    at org.apache.aries.jndi.DelegateContext.lookup(DelegateContext.java:161)
    at javax.naming.InitialContext.lookup(InitialContext.java:436)
    at org.apache.jackrabbit.core.util.db.ConnectionFactory.getJndiDataSource(ConnectionFactory.java:280)
    ... 114 more
    Caused by:
    javax.naming.NameNotFoundException: Name comp/env/jdbc not found in context "java:".
    at com.ibm.ws.naming.ipbase.NameSpace.getParentCtxInternal(NameSpace.java:1969)
    at com.ibm.ws.naming.ipbase.NameSpace.retrieveBinding(NameSpace.java:1376)
    at com.ibm.ws.naming.ipbase.NameSpace.lookupInternal(NameSpace.java:1219)
    at com.ibm.ws.naming.ipbase.NameSpace.lookup(NameSpace.java:1141)
    at com.ibm.ws.naming.urlbase.UrlContextImpl.lookupExt(UrlContextImpl.java:1436)
    at com.ibm.ws.naming.java.javaURLContextImpl.lookupExt(javaURLContextImpl.java:477)
    ... 119 more

    Okay "damorgan", you seem to have me confused with a newbie. All I'm posting is the info that I got from my Sys Admin on the fix to my problem I encountered when trying to install Oracle 11g (11.2.0.0) on Red Hat Linux Enterprise 5. Since we're mouting onto an NFS, these are the steps he took. I'm not trying to "hide" information or post as little as possible. What other info do you want? I don't know what you are referring to when you mention "Filer, make, model, software version"? Please elaborate. I was just trying to post to others that may have encountered this problem, and I get somewhat attacked by you. I don't assume anyone can read my mind (especially you).

  • Failed in WD JNDI lookup in QA  Portal

    Hello Experts,
    I am facing the issue in custom WD application in QA portal system, in dev portal the application is working fine and after transporting the objects into QA portal ,while on preview the iview its giving me error : "Failed in WD JNDI lookup ".
    I have tested the WD application from Web dynpro console and its working fine , even i have created iview in QA portal and its working fine but while transporting the iview from DEV to QA Portal is not working . Can any one help me on that .
    Your help will highly appreciated ..
    Details error :
    com.sapportals.portal.prt.runtime.PortalRuntimeException: Failed in WD JNDI lookup. javax.naming.NameNotFoundException: No child found in WebDynproContext with name home~eth_dis
        at com.sap.portal.pcm.iview.admin.AdminBaseiView.createAttrSetLayersList(AdminBaseiView.java:357)
        at com.sap.portal.pcm.iview.admin.AdminBaseiView.getAttrSetLayersList(AdminBaseiView.java:205)
        at com.sap.portal.pcm.iview.admin.AdminBaseiView.getCustomImplementation(AdminBaseiView.java:148)
        at com.sap.portal.pcm.admin.PcmAdminBase.getImplementation(PcmAdminBase.java:530)
        at com.sapportals.portal.ivs.iviews.IviewServiceObjectFactory.getObjectInstance(IviewServiceObjectFactory.java:442)
        ... 40 more

    Hi Shanti,
    Thanks for the quick response.
    My portal version is EP 7 with SP21 .As I mention in my thread that I have tested custom application on QA Portal  and its working fine. But the problem is only appearing with the transported iview into QA portal.
    Regards
    Rashi

  • Queue JNDI lookup in a clustered environment

    Hey all,
              I know in a 6.1 cluster, the queues/JMS servers can only reside on one
              server.
              How can i lookup a queue from internal code from one of the off servers? The
              JNDI lookup doesn't grab it, throws an object not found exception. Do I need
              to
              be using the createQueue() method in the QueueSession class?
              It's fairly critical to know this to get our app up on the cluster, so
              any help would
              be very appreciated!
              Thanks,
              Greg
              

              A dumb question - how do I specify JNDINameReplicated=false? I am using WLS 6.1
              SP3 and in my config.xml I have
              <JMSTopic Name="topicA" JNDIName="topicA" JNDINameReplicated="false" />
              but WebLogic does not like it.
              Eric Ma
              Tom Barnes <[email protected]> wrote:
              >The parameter name "JNDINameReplicated" parameter is only available in
              >a patch
              >on top
              >of SP2 or SP3, and is "true" by default. I doubt that you are using
              >it.
              >
              >Greg Kaestle wrote:
              >
              >> Thanks much,
              >> Where is this parameter set in config.xml?
              >>
              >> Greg
              >>
              >> "Shean-Guang Chang" <[email protected]> wrote in message
              >> news:[email protected]...
              >> > If you want the queue to be found from other server in the same cluster
              >> then
              >> > you should not set "JNDINameReplicated" to false. This
              >> > will make the JNDI name of the queue known to the local server which
              >is
              >> > hosting the JMS queue. The purpose to use "JNDINameReplicated=false"
              >> > is to have multiple queues with the same JNDI name and then use some
              >sort
              >> of
              >> > load balancer to spread load among different JMS servers in the cluster.
              >> >
              >> >
              >> > "Greg Kaestle" <[email protected]> wrote in message
              >> > news:[email protected]...
              >> > > Hey all,
              >> > >
              >> > > I know in a 6.1 cluster, the queues/JMS servers can only reside
              >on
              >> one
              >> > > server.
              >> > > How can i lookup a queue from internal code from one of the off
              >servers?
              >> > The
              >> > > JNDI lookup doesn't grab it, throws an object not found exception.
              >Do I
              >> > need
              >> > > to
              >> > > be using the createQueue() method in the QueueSession class?
              >> > >
              >> > > It's fairly critical to know this to get our app up on the cluster,
              >> so
              >> > > any help would
              >> > > be very appreciated!
              >> > >
              >> > > Thanks,
              >> > > Greg
              >> > >
              >> > >
              >> >
              >> >
              >
              

  • Redirecting failed messages to other consumers of distributed queue

    Hi,
    We have a simple cluster with two servers A and B, each hosting one MDB whose task is to consume message from a distributed queue and forward them to an EIS via a JCA resource adapter. Server B acts as a failover server. If the resource adapter is unable to deliver the message, the MDB will throw a runtime exception and the message will therefore be redelivered. In order to achieve high-availability, we have configured the distributed queue to send the redelivered message to an error destination (dead-letter-queue DLQ). The DLQ again has another instance of the MDB as a consumer with a different resource adapter.
    Using DLQs is working fine as a high-availability mechanism when the MDB is unable to deliver the message to the EIS, but is this a common or valid approach?
    An alternative to using DLQs would be to configure weblogic to send redelivered message to other consumers on the distributed queue. The problem we have is that the failed message always gets redelivered to the same MDB (i.e. the MDB which consumes messages but throws an exception because the resource adapter fails). Is it somehow possible to configure the MDB or even change the MDB code to notify weblogic to send the failed message to another consumer of the distributed queue? Would the MDB be able to disconnect the JMS connection when throwing the exception and if so, would the disconnection cause the application server to deliver the message to another consumer?
    Many thanks

    Thanks Tom,
    Setting the distributed-destination-connection property to EveryMember seems to be exactly what we need to allow other distributed queue member to consume the message which has been put back on the queue after a rollback. In order to ensure that it won't be the same MDB consuming the failed message again, we would have to temporarily suspend the MDB. From what I read, one approach is to sleep the MDB after throwing the runtime exception (but is this possible, i.e. is it not going to interrupt the onMessage before going to sleep?). I also read that there is a new property from WLS 9.0 onwards to automatically stop the MDB for a certain time after an exception has ocurred, how can I configure this? Are we also going to have to set the MDB pool size to 1 in order to ensure that the message gets consumed by an MDB on a different server?
    We have also tried to use a non-collocated approach instead using a collocated approach with distributed queues but we end up with the same problem that a message does not get redelivered to MDBs on other servers after a runtime exception has been thrown.
    Thanks a lot

  • PortalRuntimeException: Failed in WD JNDI lookup.

    Hi Experts
    We are getting the following exception when we try to run our WD application in an iView :
    com.sapportals.portal.prt.runtime.PortalRuntimeException: Failed in WD JNDI lookup. javax.naming.NameNotFoundException: No child found in WebDynproContext with name xxxxx.com
    If we deploy and run our application as such on the server,it works fine.This issue comes only after we have integrated it in the iview.
    Please provide some pointers.

    Hello Kunal
    when you integrate it in an iView, pcd address/location should be there atttributes..i think it's missing
    Bhudev

  • Javax.naming.NamingException: Failed in WD JNDI lookup

    Hi,
               I have deployed wdj applications,some times its working fine ,but some other times its through the following errors.
    javax.naming.NamingException: Failed in WD JNDI lookup
    Any one please suggest me
    Thanks,
    Venu

    Hi Friend,
    I am not sure what Other Reason can be for this problem mean while check these links. Hope it will help.
    /message/6928201#6928201 [original link is broken]
    /message/6315352#6315352 [original link is broken]
    Regards
    Jeetendra

Maybe you are looking for