NameNotFoundException when using JMS in a Cluster

Whenever I start my cluster with my test application deployed or on occasion while my cluster is running and I'm deploying my test application I get the following exception:
javax.naming.NameNotFoundException: Unable to resolve 'test'. Resolved ''; remaining name 'test'
at weblogic.jndi.internal.BasicNamingNode.newNameNotFoundException(BasicNamingNode.java:1139)
at weblogic.jndi.internal.BasicNamingNode.lookupHere(BasicNamingNode.java:252)
at weblogic.jndi.internal.ServerNamingNode.lookupHere(ServerNamingNode.java:182)
at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:206)
at weblogic.jndi.internal.WLEventContextImpl.lookup(WLEventContextImpl.java:254)
at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:380)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
Following is a snippet of code I'm using that deals with retrieving the topic named 'test':
InitialContext _initialContext = null;
try {
_initialContext = new InitialContext(environment);
_initialContext.lookup("ConnectionFactory");
try {
_initialContext.lookup("test");
} catch (NamingException exception) {
LOG.error("", exception);
} catch (NamingException exception) {
LOG.error("A naming exception has occurred!", exception);
} finally {
if (_initialContext != null) {
try {
_initialContext.close();
} catch (NamingException exception) {
LOG.error("A naming exception has occurred!", exception);
The '_initialContext.lookup("test")' invocation is the one causing the mentioned exception.
I used the snippet of code in my test Servlet's constructor, init(...) and service(...) methods. During Cluster start-up it always fails in the constructor or service(...) method. If I use the code in the service(...) method after Cluster start-up if the service(...) method is hit within a couple of seconds after Cluster start-up the exception is thrown, if I wait for a minute or so the exception is not thrown. It almost looks like the JMS Topic becomes available after some time but is not available during start-up. I would think the JMS Connection Factory and Topics should be set-up and available before invoking my test Servlet's constructor and init(...) method. Did I misconfigure something in my Cluster?
I'm using WebLogic Server 10.3. I have a cluster setup with 1 Administration Server and 3 Managed Nodes. I'm using a Node Manager on each of the nodes to start up the various WebLogic Server instances. Additionally I have the following setup:
- 1 Migratable Target (/w User Preferred Server set to node 1 and /w Constrained Candidate Servers set to nodes 1, 2 and 3)
- 1 JMS Server (targeted at the Migratable Target)
- 1 JMS Module (targeted at the Cluster)
- 1 Connection Factory (/w Default Targeting enabled resulting in the Cluster being targeted)
- 1 Subdeployment
- 1 Topic named 'test' (when defining the Subdeployment I'm only able to target it to the JMS Server)
Any help is appreciated!
Thanks,
Jack...

You can configure JMS servers to run anywhere and you can put
          your connection factories anywhere. If multiple JMS servers are
          going to share a database then they need unique table prefixes. You
          don't need any special DDL.
          _sjz.
          

Similar Messages

  • [svn] 2692: Bug: BLZ-227 - When using JMS Destination, MessageClient and FlexClient not released from memory when the session times out .

    Revision: 2692
    Author: [email protected]
    Date: 2008-07-31 13:05:35 -0700 (Thu, 31 Jul 2008)
    Log Message:
    Bug: BLZ-227 - When using JMS Destination, MessageClient and FlexClient not released from memory when the session times out.
    QA: Yes
    Doc: No
    Checkintests: Pass
    Details: Fixed a memory leak with JMS adapter. Also a minor tweak to QA build file to not to start the server if the server is already running.
    Ticket Links:
    http://bugs.adobe.com/jira/browse/BLZ-227
    Modified Paths:
    blazeds/branches/3.0.x/modules/core/src/java/flex/messaging/services/messaging/adapters/J MSAdapter.java
    blazeds/branches/3.0.x/qa/build.xml

    Revision: 2692
    Author: [email protected]
    Date: 2008-07-31 13:05:35 -0700 (Thu, 31 Jul 2008)
    Log Message:
    Bug: BLZ-227 - When using JMS Destination, MessageClient and FlexClient not released from memory when the session times out.
    QA: Yes
    Doc: No
    Checkintests: Pass
    Details: Fixed a memory leak with JMS adapter. Also a minor tweak to QA build file to not to start the server if the server is already running.
    Ticket Links:
    http://bugs.adobe.com/jira/browse/BLZ-227
    Modified Paths:
    blazeds/branches/3.0.x/modules/core/src/java/flex/messaging/services/messaging/adapters/J MSAdapter.java
    blazeds/branches/3.0.x/qa/build.xml

  • Authentication error when using JMS service

    I'm currently trying to send String messages from LiveCycle to Websphere MQ (Both running on the same server), but I'm having some problems...
    I''m quite sure that my WAS setup is correct (or at least close to correct) because I've build some test Java classes that are able to put and get messages from MQ using JMS. However, when I'm usng the LiveCycle JMS service I get the following exception thrown:
    [5/26/10 17:46:44:705 CAT] 00000027 QueueMessageS A com.adobe.livecycle.jms.QueueMessageSender sendMessageToQueueWithProperties Error occurred when creating queue connection. Reason: MQJMS2013: invalid security authentication supplied for MQQueueManager.
    Since I'm not a Websphere fundi I trawled through Google and was able to figure out that the problem probably lies with the configuration of my queue connection factory. Changing the transport type from "Bindings" to "Client" didn't resolve the problem and I'm rapidly running out of good ideas. Hopefully somebody here would be able to help.
    The following info might be useful:
    OS = Windows Server 2003
    I'm using WAS 6.1.0.29
    Websphere MQ is running on the same machine (v6.0)
    I've used the Websphere MQ JMS Provider that comes with WAS
    I've configured a Queue Connection Factory and a Queue in the server scope
    No SSL or anything like that is set up yet
    I did notice that when configuring the Queue there is a section titled "WebSphere MQ Queue Connection Properties" where I am able to specify a user Id and password. However, nothing seemed to work. I tried my WAS administration user name, as well as a windows user who is indeed a member of the mqm group. Also tried it without any value, but no luck
    On the MQ side I couldn't really find any settings under either the Queue Manager or the Channel that would make much of a difference. Since I was able to access the queues using a servlet deployed on the same WAS instance I'm thinking it has something to do with the way that LC call the JMS provider. But to be honest, I don't really have a clue.
    Any help would be much appreciated.
    Greg

    Haven't solved the problem yet, but here's an update:
    I created an "ExecureScript" operation that contains simple Java code to write a message to MQ using the same JMS connection factory and JMS queue. It does work correctly, so clearly my setup it correct enough to send messages from LiveCycle to MQ via JMS.
    Here's the code for the ExecuteScript:
    //import the classes that the script references
    import java.util.List;
    import java.lang.String;
    import java.util.Map;
    import java.util.HashMap;
    import javax.jms.*;
    import javax.naming.*;
    //get a list of file names that are stored in the process variable named files
    String strMessage = patExecContext.getProcessDataStringValue("/process_data/@strMessage");
    //get connection factory
    String strQcf = patExecContext.getProcessDataStringValue("/process_data/@strQcf");
    //get queue
    String strQ = patExecContext.getProcessDataStringValue("/process_data/@strQ");
    try
        // Look up administered objects
        System.out.println("Looking up administered objects...");
        InitialContext initContext;
        initContext = new InitialContext();
        QueueConnectionFactory factory = (QueueConnectionFactory) initContext.lookup(strQcf);
        Queue queue = (Queue) initContext.lookup(strQ);           
        initContext.close();
          // Create JMS objects
          System.out.println("Creating JMS objects...");
          QueueConnection connection = factory.createQueueConnection();
          QueueSession session =    connection.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
        QueueSender sender = session.createSender(queue);
          //Send messages
          TextMessage message = session.createTextMessage(strMessage);
          sender.send(message);
           //Exit
           System.out.println("Exiting...");
           connection.close();
           System.out.println("Goodbye!");   
    } catch (Exception e)
            e.printStackTrace();
    Interestingly I don't provide any authentication information and yet LC is able to connect to MQ
    Cheers

  • InvocationException when use JMS from RA

    Hi everybody,
    I encountered an interesting thing (I guess a bug).
    The JMS Reference Implementation on the J2EE 1.4 RI works if you use JMS API in your servlets or even in you standalone (not deployed) application.
    But when you use the same coding inside of your Resource Adapter, like
    try{
    Context jndiContext= new InitialContext();
    javax.jms.ConnectionFactory jmsConnectionFactory =
    (javax.jms.ConnectionFactory)jndiContext.lookup
    ("QueueConnectionFactory");
    javax.jms.Connection jmsConnection =
    jmsConnectionFactory.createConnection();
    javax.jms.Session jmsSession =
    jmsConnection.createSession(false,
    Session.AUTO_ACKNOWLEDGE);
    jmsConnection.close();
    }//try
    catch (java.lang.Exception ex){
    ex.printStackTrace();
    }//catch
    the Session cannot be created and following Exception is thrown
    com.sun.enterprise.InvocationException
         at com.sun.enterprise.util.InvocationManagerImpl.getCurrentInvocation(InvocationManagerImpl.java:188)
         at com.sun.enterprise.resource.PoolManagerImpl.getResource(PoolManagerImpl.java:96)
         at com.sun.enterprise.resource.ConnectionManagerImpl.internalGetConnection(ConnectionManagerImpl.java:149)
         at com.sun.enterprise.resource.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:58)
         at com.sun.jms.connector.ra.JMSConnectionAdapter.createSession(JMSConnectionAdapter.java:363)
    The only cause for this Exception I see, is that J2EE RI doesn't handles yet the case, when the JMS API calls are comming from the threads, which are issued specially for resource adapters. And since even the standalone application using default environment properties to creat an InitialContext can create a Session to a JMS queue, I don't see the reason, why the Resource Adapter shouldn't be able to do this. So I guess, that is a bug.
    But anyway, does somebody know a workaround for this case? Or just any ideas?
    Thanks,
    Eugen

    Any luck figuring this out? i'm getting the same exception when appserver 8 does an auto reload of my webapp. For some reason the jdbc connection pools are messed up at that point.

  • Deadlock in TopLink when using JMS listener on WebLogic

    I am experiencing a deadlock in TopLink 10.1.3 on WebLogic 9 in code that previously worked on TopLink 9.0.4 with WebLogic 8.1. As such, I'm not sure if it's due to the TopLink change, the WebLogic change or both. Anyway, we have a JMS listener (note, NOT a MessageDrivenBean) that is updating an existing TopLink cached domaing object. The JMS listener thread gets stuck when attempting to commit the transaction. The thread-dump shows that there is another thread which is blocked in the ConcurrencyManager waiting to obtain the lock on an object which is being updated by the listener thread. It appears to me that the root cause is that the Synchronization.afterCompletion() listener is running on a different thread than the one which owns the locks which were obtained beforeCompletion.
    See stack traces.
    First, the message listener thread which is waiting for participants in the transaction to commit:
    "[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon prio=9 tid=0x3a4a4728 nid=0xa48 in Object.wait() [0x3a0cf000..0x3a0cfbec]
         at java.lang.Object.wait(Native Method)
         - waiting on <0x0c7a0908> (a weblogic.transaction.internal.ServerTransactionImpl)
         at weblogic.transaction.internal.ServerTransactionImpl.globalRetryCommit(ServerTransactionImpl.java:2665)
         - locked <0x0c7a0908> (a weblogic.transaction.internal.ServerTransactionImpl)
         at weblogic.transaction.internal.ServerTransactionImpl.globalCommit(ServerTransactionImpl.java:2570)
         at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:277)
         at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:226)
         at weblogic.ejb.container.internal.BaseEJBObject.postInvoke1(BaseEJBObject.java:539)
         at weblogic.ejb.container.internal.StatelessEJBObject.postInvoke1(StatelessEJBObject.java:72)
         at weblogic.ejb.container.internal.BaseEJBObject.postInvokeTxRetry(BaseEJBObject.java:374)
         at com.avinamart.BusinessLogic.Bean.JobService.JobService_u1ylwo_EOImpl.submitJobAndRun(JobService_u1ylwo_EOImpl.java:1388)
         at com.avinamart.Framework.Event.Task.OptimizationTaskListener._submitAsAJob(OptimizationTaskListener.java:253)
         at com.avinamart.Framework.Event.Task.OptimizationTaskListener._submitAsAJob(OptimizationTaskListener.java:217)
         at com.avinamart.Framework.Event.Task.OptimizationTaskListener.processMessage(OptimizationTaskListener.java:344)
         at com.emptoris.base.event.EPASSMessageBaseListener.onMessage(EPASSMessageBaseListener.java:722)
         at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:3824)
         at weblogic.jms.client.JMSSession.execute(JMSSession.java:3738)
         at weblogic.jms.client.JMSSession.pushMessage(JMSSession.java:3253)
         at weblogic.jms.client.JMSSession.invoke(JMSSession.java:4195)
         at weblogic.messaging.dispatcher.Request.wrappedFiniteStateMachine(Request.java:674)
         at weblogic.messaging.dispatcher.DispatcherServerRef.invoke(DispatcherServerRef.java:262)
         at weblogic.messaging.dispatcher.DispatcherServerRef.handleRequest(DispatcherServerRef.java:134)
         at weblogic.messaging.dispatcher.DispatcherServerRef.access$000(DispatcherServerRef.java:36)
         at weblogic.messaging.dispatcher.DispatcherServerRef$1.run(DispatcherServerRef.java:105)
         at weblogic.work.ExecuteThread.execute(ExecuteThread.java:207)
         at weblogic.work.ExecuteThread.run(ExecuteThread.java:179)
    Next, the other thread which is participating in the transaction which is stuck:
    "[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon prio=5 tid=0x3adb80a0 nid=0xb30 in Object.wait() [0x3c7af000..0x3c7afd6c]
         at java.lang.Object.wait(Native Method)
         - waiting on <0x0c7a0000> (a oracle.toplink.internal.helper.ConcurrencyManager)
         at java.lang.Object.wait(Object.java:474)
         at oracle.toplink.internal.helper.ConcurrencyManager.acquire(ConcurrencyManager.java:76)
         - locked <0x0c7a0000> (a oracle.toplink.internal.helper.ConcurrencyManager)
         at oracle.toplink.internal.identitymaps.CacheKey.acquire(CacheKey.java:80)
         at oracle.toplink.internal.identitymaps.FullIdentityMap.remove(FullIdentityMap.java:164)
         at oracle.toplink.internal.identitymaps.HardCacheWeakIdentityMap.remove(HardCacheWeakIdentityMap.java:82)
         at oracle.toplink.internal.helper.WriteLockManager.releaseAllAcquiredLocks(WriteLockManager.java:363)
         at oracle.toplink.publicinterface.UnitOfWork.afterTransaction(UnitOfWork.java:2123)
         at oracle.toplink.transaction.AbstractSynchronizationListener.afterCompletion(AbstractSynchronizationListener.java:135)
         at oracle.toplink.transaction.JTASynchronizationListener.afterCompletion(JTASynchronizationListener.java:66)
         at weblogic.transaction.internal.ServerSCInfo.callAfterCompletions(ServerSCInfo.java:862)
         at weblogic.transaction.internal.ServerTransactionImpl.callAfterCompletions(ServerTransactionImpl.java:2913)
         at weblogic.transaction.internal.ServerTransactionImpl.afterCommittedStateHousekeeping(ServerTransactionImpl.java:2806)
         at weblogic.transaction.internal.ServerTransactionImpl.setCommittedUnsync(ServerTransactionImpl.java:2857)
         at weblogic.transaction.internal.ServerTransactionImpl.ackCommit(ServerTransactionImpl.java:1097)
         - locked <0x0c7a0908> (a weblogic.transaction.internal.ServerTransactionImpl)
         at weblogic.transaction.internal.CoordinatorImpl.ackCommit(CoordinatorImpl.java:211)
         at weblogic.transaction.internal.CoordinatorImpl_WLSkel.invoke(Unknown Source)
         at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:517)
         at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:407)
         at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
         at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:147)
         at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:403)
         at weblogic.rmi.internal.BasicServerRef.access$300(BasicServerRef.java:56)
         at weblogic.rmi.internal.BasicServerRef$BasicExecuteRequest.run(BasicServerRef.java:934)
         at weblogic.work.ExecuteThread.execute(ExecuteThread.java:207)
         at weblogic.work.ExecuteThread.run(ExecuteThread.java:179)
    Is this the same concurrency bug which was fixed in 10.1.3.1??? As I am writing this, I am attempting to build the application with the updated TopLink jar to test for myself. Has anyone else seen this scenario with WebLogic? I should also point out that the problem only occurs when the listener is running on a separate server than the one hosting the JMS queue it reads from. It may be that when the listener runs on the same server, it does not use multiple threads in the transaction.
    Any ideas are greatly appreciated.
    - Bruno

    We've got the same kind of issue with toplink 10.1.3.0.0 and bea weblogic 8.1 SP5.
    I 've not tried with 10.1.3.1.0, did you?
    Do you have a new status for this issue.
    Chris

  • Compressor jobs fail when using a 6 instance cluster

    Hello all,
    The last week or so, any file I send to Compressor and use my quick cluster with 6 instances fail. Not only does it fail it locks up my entire system!
    Does anybody know what's going on?
    Thanks

    This works great when bringing files into compressor to be converted to other formats, such as a QuickTime Movie... but, I have not had any luck trying to export this way directly from FCP. I've tried on multiple machines and I always get the error "Failed - HOST ["Machine Name".local] Final Cut Pro.app generated an error or unexpectedly quitUser aborted Media Server. Then it tries to cancel the export but just sits there until I either Force Quit FCP, stop sharing in Apple Qmaster or restart the machine. Should this be working as far as sending FCP projects to compressor for export, or will it only work by bringing in an already exported file? Anyone have any ides or suggestions?

  • No output when using ODA in WS Cluster

    I am trying to dynamically assemble multiple documents using the new On Demand Assmebly module in a WebSphere cluster with a load balanced cluster of web servers in front of LC. While the process calls the ODA successfully, the output document is empty. Yes, I am building and passing a DXFA file to the ODA.
    This is the same behavior I experienced while running the "old" DDG solution accelerator in the same environment - although the DDG would work approximately 50% of the time, depending on which server was being hit between process steps. BTW - the DDG also functioned correctly in a single server enviroment. (ok - the Turnkey on JBoss; which I would certainly expect to work)

    While the URL for ODAWebApp was originally pointed at the web server/load balancer - I have changed it to point to one server on the cluster. Additionally, to aid in testing, we have disabled one of the app servers on the cluster to force all activity on the same server. (it was the only way to get the old DDG to work consistently) Regardless, after changing the URL, the ODA still does not produce any output. The XDP's are currently on a file system. I have not tried retrieving them from the repository (the old DDG could not retrieve them from the repository in our cluster, so we copied the XDP's to a file system on shared disk ) I can change the script/DXFA to retrieve the XDP's from the repository to see if that works. The XDFA file is also the same exact file (built with the same script) that we use with the DDG. I will examine the tech notes again to see if there is a difference required. We have recycled that server and still get the same result. I will install the ODA debug later and report the results.

  • Convert JMS Headers from EBCDIC to ASCII when using JMS Bridge (WLS - WMQ)

    I have a Java app on Weblogic 11g using a Message Bridge to talk JMS with IBM Websphere MQ. The MQ server is running on IBM z/OS platform which uses EBCDIC encoding. I need to use the Weblogic message selector feature to filter messages on the bridge coming from Websphere MQ. But the JMS Headers of MSGs posted by WMQ are in EBCDIC format. How can I instruct MQ to convert the msg headers to ASCII before put on the bridge? Is there any flag on bindings config file? Or can I set some WMQ specific header before sending the msg on WLS side?
    Thanks in advance.

    Hi,
    Such option is not possible in weblogic but I think this property will help you with in MQ.
    Property - Convert EBCDIC newline
    Description - EBCDIC code pages contain a new line (NL) character that is not supported by the ASCII code pages (although some ISO variants of ASCII contain an equivalent). If messages are sent from a system that uses EBCDIC code pages (for example, a z/OS system) to a system that uses ASCII, you can control how the EBCDIC newline character is converted into ASCII format.
    The default value is NL_TO_LF, which means that the EBCDIC NL character (X'15') is converted to the ASCII line feed character LF (X'0A') for all EBCDIC to ASCII conversions. To convert the EBCDIC NL character according to the conversion tables on your operating system, click TABLE. Note that the results of a TABLE conversion can vary from platform to platform and from language to language; even on the same platform the results might vary if you use different coded character set identifiers (CCSIDs). To convert ISO CCSIDs using the TABLE method and use the NL_TO_LF method for all other CCSIDs, click ISO.
    Registry Stanza Key - ConvEBCDICNewline
    Also, the MQSeries (not MQSC) adapter provides the data conversion property may handle this conversion as well.
    Regards,
    Kal

  • Transactional error when using JMS from stateless session bean

    I get a transaction exception when committing a bean method responsible for sending to a JMS topic. This happens only occasionally when two separate threads invoke this method "at the same time".
    The scenario:
    Two separate threads running two different instances of a stateless session bean (slsb A). This ejb (slsb A) has an injected slsb B which is communicating with the the topic.
    Both instances of slsb A are utilising the same instance of slsb B.
    The CMT transactions for the two threads start in slsb A from methods with transaction attribute "RequiresNew". All nested methods are to other slsbs and have the transaction attribute "Required". The method in slsb B which sends the message is closing both the session and the connection to the topic.
    I'm running Glassfish version 9.1_02 (build b04-fcs) and JMS implementation OpenMQ version 4.1.
    Stacktrace (glassfish log):
    [#|2008-09-09T13:00:40.515+0200|SEVERE|sun-appserver9.1|javax.resourceadapter.mqjmsra.outbound.connection|_ThreadID=18;_ThreadName=httpSSLWorkerThread-8080-1;_RequestID=108e8418-71a6-4d8b-a94d-9e1edc885891;|commitTransaction (XA) on JMSService:jmsdirect failed for connectionId:5754505514139844608 and onePhase:false due to unkown JMSService server error.|#]
    [#|2008-09-09T13:00:40.515+0200|SEVERE|sun-appserver9.1|javax.enterprise.system.core.transaction|_ThreadID=18;_ThreadName=httpSSLWorkerThread-8080-1;org.omg.CORBA.INTERNAL:   vmcid: 0x0  minor code: 0 completed: Maybe;commit;_RequestID=108e8418-71a6-4d8b-a94d-9e1edc885891;|JTS5031: Exception [org.omg.CORBA.INTERNAL:   vmcid: 0x0  minor code: 0 completed: Maybe] on Resource [commit] operation.|#]
    [#|2008-09-09T13:00:40.531+0200|INFO|sun-appserver9.1|javax.enterprise.system.container.ejb|_ThreadID=18;_ThreadName=httpSSLWorkerThread-8080-1;SubscriptionBean;|EJB5018: An exception was thrown during an ejb invocation on [SubscriptionBean]|#]
    [#|2008-09-09T13:00:40.531+0200|INFO|sun-appserver9.1|javax.enterprise.system.container.ejb|_ThreadID=18;_ThreadName=httpSSLWorkerThread-8080-1;|
    javax.ejb.EJBException: Unable to complete container-managed transaction.; nested exception is: javax.transaction.SystemException: org.omg.CORBA.INTERNAL: JTS5031: Exception [org.omg.CORBA.INTERNAL:   vmcid: 0x0  minor code: 0 completed: Maybe] on Resource [commit] operation. vmcid: 0x0 minor code: 0 completed: No
    javax.transaction.SystemException: org.omg.CORBA.INTERNAL: JTS5031: Exception [org.omg.CORBA.INTERNAL:   vmcid: 0x0  minor code: 0 completed: Maybe] on Resource [commit] operation. vmcid: 0x0 minor code: 0 completed: No
         at com.sun.jts.jta.TransactionManagerImpl.commit(TransactionManagerImpl.java:321)
         at com.sun.enterprise.distributedtx.J2EETransactionManagerImpl.commit(J2EETransactionManagerImpl.java:1030)
         at com.sun.enterprise.distributedtx.J2EETransactionManagerOpt.commit(J2EETransactionManagerOpt.java:397)
         at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:3792)
         at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:3585)
         at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1354)
         at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1316)
         at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:205)
         at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:127)
         at $Proxy130.requestNewSubscription(Unknown Source)
         at com.abeldrm.kms.core.services.subscription.SubscriptionWSBean.requestNewSubscription(SubscriptionWSBean.java:94)
         at sun.reflect.GeneratedMethodAccessor127.invoke(Unknown Source)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:597)
         at com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1067)
         at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
         at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2895)
         at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:3986)
         at com.sun.ejb.containers.WebServiceInvocationHandler.invoke(WebServiceInvocationHandler.java:189)
         at $Proxy129.requestNewSubscription(Unknown Source)
         at sun.reflect.GeneratedMethodAccessor126.invoke(Unknown Source)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:597)
         at com.sun.enterprise.webservice.InvokerImpl.invoke(InvokerImpl.java:81)
         at com.sun.enterprise.webservice.EjbInvokerImpl.invoke(EjbInvokerImpl.java:82)
         at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:146)
         at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:257)
         at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:93)
         at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
         at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
         at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
         at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
         at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:106)
         at com.sun.enterprise.webservice.MonitoringPipe.process(MonitoringPipe.java:147)
         at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
         at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
         at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
         at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
         at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
         at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:106)
         at com.sun.xml.ws.tx.service.TxServerPipe.process(TxServerPipe.java:329)
         at com.sun.enterprise.webservice.CommonServerSecurityPipe.processRequest(CommonServerSecurityPipe.java:218)
         at com.sun.enterprise.webservice.CommonServerSecurityPipe.process(CommonServerSecurityPipe.java:129)
         at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
         at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
         at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
         at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
         at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
         at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:243)
         at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:444)
         at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244)
         at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:135)
         at com.sun.enterprise.webservice.Ejb3MessageDispatcher.handlePost(Ejb3MessageDispatcher.java:113)
         at com.sun.enterprise.webservice.Ejb3MessageDispatcher.invoke(Ejb3MessageDispatcher.java:87)
         at com.sun.enterprise.webservice.EjbWebServiceServlet.dispatchToEjbEndpoint(EjbWebServiceServlet.java:226)
         at com.sun.enterprise.webservice.EjbWebServiceServlet.service(EjbWebServiceServlet.java:155)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
         at com.sun.enterprise.web.AdHocContextValve.invoke(AdHocContextValve.java:114)
         at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
         at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
         at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:87)
         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206)
         at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
         at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
         at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150)
         at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
         at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
         at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
         at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:272)
         at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637)
         at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568)
         at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813)
         at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341)
         at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263)
         at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214)
         at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
         at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)
    IMQ broker log:
    [09/Sep/2008:13:00:40 CEST] ERROR CommitTransaction: commit failed. Connection ID: 5754505514139844608, Transaction ID: 0:
    com.sun.messaging.jmq.jmsserver.util.BrokerException: Unknown Transaction 0
         at com.sun.messaging.jmq.jmsserver.data.protocol.ProtocolImpl.commitTransaction(ProtocolImpl.java:630)
         at com.sun.messaging.jmq.jmsserver.service.imq.IMQDirectService.commitTransaction(IMQDirectService.java:1735)
         at com.sun.messaging.jms.ra.DirectXAResource.commit(DirectXAResource.java:201)
         at com.sun.jts.jtsxa.OTSResourceImpl.commit(OTSResourceImpl.java:114)
         at com.sun.jts.CosTransactions.RegisteredResources.distributeCommit(RegisteredResources.java:795)
         at com.sun.jts.CosTransactions.TopCoordinator.commit(TopCoordinator.java:2111)
         at com.sun.jts.CosTransactions.CoordinatorTerm.commit(CoordinatorTerm.java:403)
         at com.sun.jts.CosTransactions.TerminatorImpl.commit(TerminatorImpl.java:249)
         at com.sun.jts.CosTransactions.CurrentImpl.commit(CurrentImpl.java:623)
         at com.sun.jts.jta.TransactionManagerImpl.commit(TransactionManagerImpl.java:309)
         at com.sun.enterprise.distributedtx.J2EETransactionManagerImpl.commit(J2EETransactionManagerImpl.java:1030)
         at com.sun.enterprise.distributedtx.J2EETransactionManagerOpt.commit(J2EETransactionManagerOpt.java:397)
         at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:3792)
         at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:3585)
         at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1354)
         at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1316)
         at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:205)
         at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:127)
         at $Proxy130.requestNewSubscription(Unknown Source)
         at com.abeldrm.kms.core.services.subscription.SubscriptionWSBean.requestNewSubscription(SubscriptionWSBean.java:94)
         at sun.reflect.GeneratedMethodAccessor127.invoke(Unknown Source)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:597)
         at com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1067)
         at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
         at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2895)
         at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:3986)
         at com.sun.ejb.containers.WebServiceInvocationHandler.invoke(WebServiceInvocationHandler.java:189)
         at $Proxy129.requestNewSubscription(Unknown Source)
         at sun.reflect.GeneratedMethodAccessor126.invoke(Unknown Source)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:597)
         at com.sun.enterprise.webservice.InvokerImpl.invoke(InvokerImpl.java:81)
         at com.sun.enterprise.webservice.EjbInvokerImpl.invoke(EjbInvokerImpl.java:82)
         at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:146)
         at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:257)
         at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:93)
         at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
         at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
         at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
         at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
         at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:106)
         at com.sun.enterprise.webservice.MonitoringPipe.process(MonitoringPipe.java:147)
         at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
         at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
         at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
         at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
         at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
         at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:106)
         at com.sun.xml.ws.tx.service.TxServerPipe.process(TxServerPipe.java:329)
         at com.sun.enterprise.webservice.CommonServerSecurityPipe.processRequest(CommonServerSecurityPipe.java:218)
         at com.sun.enterprise.webservice.CommonServerSecurityPipe.process(CommonServerSecurityPipe.java:129)
         at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
         at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
         at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
         at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
         at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
         at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:243)
         at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:444)
         at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244)
         at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:135)
         at com.sun.enterprise.webservice.Ejb3MessageDispatcher.handlePost(Ejb3MessageDispatcher.java:113)
         at com.sun.enterprise.webservice.Ejb3MessageDispatcher.invoke(Ejb3MessageDispatcher.java:87)
         at com.sun.enterprise.webservice.EjbWebServiceServlet.dispatchToEjbEndpoint(EjbWebServiceServlet.java:226)
         at com.sun.enterprise.webservice.EjbWebServiceServlet.service(EjbWebServiceServlet.java:155)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
         at com.sun.enterprise.web.AdHocContextValve.invoke(AdHocContextValve.java:114)
         at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
         at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
         at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:87)
         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206)
         at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
         at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
         at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150)
         at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
         at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
         at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
         at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:272)
         at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637)
         at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568)
         at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813)
         at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341)
         at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263)
         at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214)
         at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
         at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)
    Have anyone any idea why this should fail?
    Regards,
    Jon

    I would suggest opening a case with [email protected] FWIW, I recall seeing
              something like this in WLS 6.0. I believe it is fixed in WLS 6.1
              -- Rob
              Chris Dupuy wrote:
              > Btw, this occurs when I create an stateful session bean that ends up
              > throwing an exception and setRollbackOnly() is called. From that point
              > forward, my logs fill with this message.
              >
              > Chris
              >
              > "Chris Dupuy" <[email protected]> wrote in message
              > news:[email protected]..
              > > anyone know what this means, and what you can do about it?
              > >
              > >
              > > <Error> <ConnectionManager> <atossd03> <cbeyondServer> <ExecuteThread:
              > '14'
              > > for queue: 'd
              > > efault'> <> <> <000000> <Closing:
              > 'weblogic.rjvm.t3.T3JVMConnection@488831'
              > > because of: 'Server received a message over an uniniti
              > > alized connection: 'JVMMessage from: 'null' to:
              > >
              > '5825313123619479267S:10.6.6.40:[8000,8000,8001,8001,8000,8001,-1]:cbeyond:c
              > > beyond
              > > Server' cmd: 'CMD_REQUEST', QOS: '101', responseId: '2', invokableId: '1',
              > > flags: 'JVMIDs Not Sent, TX Context Not Sent', abbrev o
              > > ffset: '204'''>
              > >
              > >
              > >
              

  • Memory leak when using JMS Cache Coordination

    We have two Weblogic Server 8.1 processes running Java 1.4.2 on Solaris using TOPLink 10.1.3 with JMS Cache Coordination. We observe that heap is filled with uncollectable instances of TOPLink-mapped classes. In our production system, under full load, this completely fills a 3.6 GB heap in 30 minutes, requiring a process restart. The problem goes away if we turn off cache coordination.
    It appears that these instances are UnitOfWork or some other kind of toplink-created clone. We have not yet been able to successfully analyse this problem with a heap profiler.
    Has anyone else experienced this this problem? Any suggestions for debugging?
    Thanks in advance.

    We do set the command manager to asychronous mode. (Our debug tracing confirms that the CommandPropagator method asynchronousPropagateCommand() is invoked, not synchronousPropagateCommand().) We started with asynchronous messaging and actually have never tried running in a synchronous mode.
    The Java bug I referenced in my last post (which I have confirmed with a stand-alone test case) indicates that, for Java 1.4.2 and earlier, is is never ok to not start() a Thread -- it will always produce a memory leak. So I am quite surprised than anyone on a pre-1.5 Java had ever had success with synchronous cache coordination messaging. Do you think it is possible all of the pre-release tests and existing customers installations of 10.1.3 cache coordination are using Java 1.5 ?!
    Our heap profiling indicates that the instances of CommandPropagator which are pinned (i.e., those not started) are allocated in the run() method of CommandPropagator itself. So it seems that the instance of CommandPropagator, after it is started, allocates another one in its run method. Looking at the bytecodes for the run() method (using javap -c) shows that in one branch of the code a second CommandPropagator is indeed allocated and then handed off to the launchContainerRunnable method of a ServerPlatform.
    Since these secondary CommandPropagators are the ones which are not started, we have looked into the WebLogic_8_1_Platform class and found that its implementation launchContainerRunnable (inherited from ServerPlatformBase) does a
    new Thread(runnable).start()where the argument runnable is the CommandPropagator.
    So the CommandPropagator itself is not started(), but is instead run an another Thread.
    We are experimenting with a custom ServerPlatform which overrides launchContainerRunnable:
        server.setServerPlatform(
            new WebLogic_8_1_Platform(server)
                public void launchContainerRunnable(Runnable runnable)
                   if (runnable instanceof Thread) ((Thread)runnable).start();
                   else super.launchContainerRunnable(runnable);
        );  This starts the argument Runnable directly if it is actually a Thread. Our early, small-scale tests indicate that this change eliminates the memory leak. We are testing now in a production-replicate environment under full load.
    But this feels like a hack. I have no idea what TOPLink behavior other than cache coordination flows through this method. Does anyone know what else this ServerPlatform method is used for? Is there a better way to do this? Are there any adverse conquences to our hack? Any suggestions would be appreciated.
    Thanks in advance.

  • Problem with JMS migration when using Ctrl+C to stop the managed server in cluster

              Hi,
              I am having a clustered weblogic application running on Weblogic 7.0 SP5. My application
              uses JMS as a asynchrous communication. We have MDB which listens to these JMS
              messages.
              If something is being processed on Managed Server 1 and while the request is in
              process, i am stopping the the MAnaged SErver 1 using Ctrl+C.
              After this, i go to admin console and migrate teh JTA and JMS. After this, i am
              expecting other running Managed Server should restart the incomplete transaction.
              But this is not happening. The Managed Serve2 doesn't process the requst.
              But when i restart teh MAnaged SErver 1 again, it takes up the same request and
              processes it.
              Is this a known problem with Weblogic that it doesn't support Ctlr+C case?
              Please note that the same thing is working fine when i stop the server using Admin
              console(Normal shutdown OR forced shutdown).
              Any comments in this regards are apprecciated.
              Thanks,
              Naresh
              

              Hi,
              I am having a clustered weblogic application running on Weblogic 7.0 SP5. My application
              uses JMS as a asynchrous communication. We have MDB which listens to these JMS
              messages.
              If something is being processed on Managed Server 1 and while the request is in
              process, i am stopping the the MAnaged SErver 1 using Ctrl+C.
              After this, i go to admin console and migrate teh JTA and JMS. After this, i am
              expecting other running Managed Server should restart the incomplete transaction.
              But this is not happening. The Managed Serve2 doesn't process the requst.
              But when i restart teh MAnaged SErver 1 again, it takes up the same request and
              processes it.
              Is this a known problem with Weblogic that it doesn't support Ctlr+C case?
              Please note that the same thing is working fine when i stop the server using Admin
              console(Normal shutdown OR forced shutdown).
              Any comments in this regards are apprecciated.
              Thanks,
              Naresh
              

  • When using rabbitmq-jms for vFabric RabbitMQ javax.jms.Message.getJMSDestination does not return the actual destination when it is received from a consumer listening on a Topic with a wild card

    When using rabbitmq-jms for vFabric RabbitMQ javax.jms.Message.getJMSDestination does not return the actual destination when it is received from a consumer listening on a Topic with a wild card. I have tested with both 1.0.3 and 1.0.5 clients with RabbitMQ 3.1.5.
    I was wondering if the community was aware of this problem and if there are any workarounds? If not what is the proper channel to file a bug report. An example code snippet is below. The test fails because the TextMessageMatcher expects the destination passed in on construction (second parameter) to equal the desination on the message received (aquired from getJMSDestination).
            Mockery context = new Mockery();
            final MessageListener messageListener = context.mock(MessageListener.class);
            final Latch latch = new LatchImpl();
            final String prefix = "test" + System.currentTimeMillis();
            context.checking(new Expectations() {
                    oneOf(messageListener).onMessage(with(new TextMessageMatcher("MSG1", prefix + ".1234")));
                    will(new CustomAction("release latch") {
                        @Override
                        public Object invoke(Invocation invocation) throws Throwable {
                            latch.unlatch();
                            return null;
            final Connection connection = createConnection(null, null);
            Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
            connection.start();
            Topic wildcardTopic = (Topic) getInitialContext().lookup(prefix + "." + "#");
            Topic destination = (Topic) getInitialContext().lookup(prefix + ".1234");
            final MessageConsumer consumer = session.createConsumer(wildcardTopic);
            consumer.setMessageListener(messageListener);
            MessageProducer producer = session.createProducer(null);
            producer.send(destination, session.createTextMessage("MSG1"));
            latch.await(5000);
            connection.close();
            Thread.sleep(5);
            context.assertIsSatisfied();

    Check where your MDB sends the [response] messages to.

  • 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

  • Are there any risks when using useMessageListener="true" for JMS Adapter?

    As far as I heard there are some risks when using
    useMessageListener="true"
    (instead of "false"). Is this true?
    Or does the Partnerlink to JMS adapter became unstable?
    When exactly is it recommended to use "true" instead of "false"?
    Peter

    Hi Peter,
    What version are you using : 10.1.2 or 10.1.3 ? By default in 10.1.3 the JMS wizard sets the useMessageListener to False . I would recommned to keep it to this value unless there is a strong reason to change otherwise.
    BR,
    Mihai

  • When we should use JMS based proxy services and when JMS Adapter in OSB

    Hi,
    Can somebody explain me when we could go for JMS Adapter and when we should go for JMS based service in OSB?
    The one scenerio i can think of is when my provider/consumer is using jms provider other than WLS jms provider we should use jms adapter.
    Edited by: user12883209 on Jan 5, 2012 5:29 AM

    I don't think there are clear guidelines available, however here is my view.
    1) OSB 11gR1 is not certified with Oracle JMS Adapter. It is certified with Oracle FTP, Database, AQ and application adapters.
    http://docs.oracle.com/cd/E21764_01/doc.1111/e15867/interop.htm#OSBAG1403
    2) In addition of the Weblogic JMS, OSB can also integrate with following provider without using adapter.
    - WebSphere MQ
    - Tibco EMS
    3) if you need to integrate JMS with BPEL Process or Oracle SOA suite composite, it has built in support for generic Oracle JMS adapter. Oracle generic JMS adapter can integrate with AQ JMS (JMS providers OJMS 8.1.7, 9.0.1.4, and 9.2), TIBCO JMS, IBM Websphere MQSeries (IBM MQSeries JMS 6.0), Weblogic JMS, Apache, and Active MQ
    http://docs.oracle.com/cd/E14571_01/integration.1111/e10231/adptr_jms.htm
    4) If you need to integrate OSB with Weblogic JMS, WebSphere MQ, Tbco EMS it does not need JMS adapter.
    Hope this helps !!!
    Jayesh Patel
    http://jayesh-patel.blogspot.com/
    http://www.yagnasys.com/

Maybe you are looking for

  • Adobe send does not work

    5 attempts to upload a file of less than 200MB using Firefox & IE and when the file upload reaches 100% an error message flashes the file could not be uploaded, a really poor show from a company as big as adobe I have cancelled my auto renewal & won'

  • Remove crashed app that will not update?

    I tried to install an update to iOS Chrome app on my iPad 3. the download crashed and would not restart, and the original app would not launch. So I deleted it. Now it's gone, but I can't reinstall Chrome because the AppStore seems to think its alrea

  • Positioning video in fixed layout epub

    Hi. How can i positioning video in fixed layout page? here is the xhtml contents. <video src="videos/video1.mp4" poster="images/video1.png" width="300" height="200" preload="auto" controls="true"></video> I want to change position of video but don`t

  • Mail Crashes When Opened Everytime on 3G iPhone

    Well, I have had this problem since I first upgraded from my first generation iPhone. When i click on the Mail.app it hangs for a couple seconds and then crashes and brings me back to my homescreen. I then was going to go ahead and just try to delete

  • Premiere CS4 wont read .MOV files

    Hi there, Hoping someone could help me with this, Premiere doesn't seem to want to read the .Mov files I need to use in the project. Is there a way I can overcome this directly? If not, does someone have a converter they could recommend, preferably f