JMS timeout

I have read quite a bit on these groups about JMS and session beans,
          but I still haven't found an answer. Let me explain my problem:
          First off I am using Weblogic 5.x
          I have a stateless session bean that, amongst other things, calls
          a method on an external class which is repsonsible for sending a JMS
          message. This external class sets up the JMS connection, session,
          queue, etc.. The problem is, the receiver always times out when it
          tries to receive a message. Can this be avoided? I have moved the
          call to the method outside the UserTransaction (I would prefer it to
          be inside), and tried transacted and non transacted JMS sessions. Is
          there anyway to not have the JMS timeout while inside an EJB? Any
          information would be greatly appreciated. Thanks.
          Tomato
          

Is there no chance you can change your architecture
to use a MessageListener?
Unfortunately thats not an option any more.
I've always found JMS to be attrocious when it comes
to synchronous messaging - guarranteeing you will
receive a message within a certain time-frame is
pretty much impossible.In that case would putting a loop be helpful, specially to avoid queues being locked?

Similar Messages

  • JMS TIMEOUT, cache out of synch

    I have a message bean, weblogic 6.1 sp3, that's timing out. The transaction type is set to required. Cache is used with version stored in the cache. When the timeout occurs for whatever reason the version in the database table, Oracle 8.1.7 is updated but the version in the cache is not. On the next query an exception is thrown. Version in cache is out of synch with that in the database.
    Exception thrown is below
    ####<Aug 3, 2003 4:05:18 PM CDT> <Error> <EDWhiteboard> <vumcportal1> <edisServer> <ExecuteThread: '10' for queue: 'default'> <guest> <> <000000>
    <EXCEPTION: StatsCollectorDAO:updateCurrWbStats() 5:
    EXCEPTION DESCRIPTION: Exception occurred within JTS.
    INTERNAL EXCEPTION: weblogic.transaction.RollbackException: Transaction timed out after 59 seconds
    Xid=13474:af8a0fba65bcc42e(5631273),Status=Active (PrePreparing),
    numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=59,seconds left=60,activeThread=Thread[ExecuteThread: '10' for queue: 'default',5,Thread Group for Queue: 'default'],SCInfo[edisdomain+edisServer]=(state=pre-preparing),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=edisServer+160.129.51.156:2206+edisdomain+,
    Resources={})],CoordinatorURL=edisServer+160.129.51.156:2206+edisdomain+) - with nested exception:
    [weblogic.transaction.internal.TimedOutException: Transaction timed out after 59 seconds
    Xid=13474:af8a0fba65bcc42e(5631273),Status=Active (PrePreparing),numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=59,seconds left=60,activeThread=Thread[ExecuteThread: '10' for queue: 'default',5,Thread Group for Queue: 'default'],SCInfo[edisdomain+edisServer]=(state=pre-preparing),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=edisServer+160.129.51.156:2206+edisdomain+, Resources={})],CoordinatorURL=edisServer+160.129.51.156:2206+edisdomain+)]>
    LOCAL EXCEPTION STACK:
    EXCEPTION [TOPLINK-7061] (TopLink - 9.0.3 (Build 423)): oracle.toplink.exceptions.ValidationException
    EXCEPTION DESCRIPTION: Exception occurred within JTS.
    INTERNAL EXCEPTION: weblogic.transaction.RollbackException: Transaction timed out after 59 seconds
    Xid=13474:af8a0fba65bcc42e(5631273),Status=Active (PrePreparing),numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=59,seconds left=60,activeThread=Thread[ExecuteThread: '10' for queue: 'default',5,Thread Group for Queue: 'default'],SCInfo[edisdomain+edisServer]=(state=pre-preparing),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=edisServer+160.129.51.156:2206+edisdomain+, Resources={})],CoordinatorURL=edisServer+160.129.51.156:2206+edisdomain+) - with nested exception:
    [weblogic.transaction.internal.TimedOutException: Transaction timed out after 59 seconds
    Xid=13474:af8a0fba65bcc42e(5631273),
    Status=Active (PrePreparing),numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=59,seconds left=60,activeThread=Thread[ExecuteThread: '10' for queue: 'default',5,Thread Group for Queue: 'default'],SCInfo[edisdomain+edisServer]=(state=pre-preparing),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=edisServer+160.129.51.156:2206+edisdomain+, Resources={})],CoordinatorURL=edisServer+160.129.51.156:2206+edisdomain+)]
         at oracle.toplink.exceptions.ValidationException.jtsExceptionRaised(Unknown Source)
         at oracle.toplink.jts.JTSExternalTransactionController.commitTransaction(Unknown Source)
    at oracle.toplink.publicinterface.Session.commitExternalTransaction(Unknown Source)
         at oracle.toplink.publicinterface.UnitOfWork.commitInternallyStartedExternalTransaction(Unknown Source)
         at oracle.toplink.publicinterface.UnitOfWork.commit(Unknown Source)
         at vanderbilt.ed.stats.data.StatsCollectorDAO.updateCurrWbStats(StatsCollectorDAO.java:127)
         at vanderbilt.ed.stats.WbStatsDelegate.updateCurrWbStats(WbStatsDelegate.java:79)
         at vanderbilt.ed.stats.ejb.EdisStatsBean.onMessage(EdisStatsBean.java:147)
         at weblogic.ejb20.internal.MDListener.execute(MDListener.java:262)
         at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:214)
         at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:1865)
         at weblogic.jms.client.JMSSession.execute(JMSSession.java:1819)
         at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
         at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
    INTERNAL EXCEPTION STACK:
    weblogic.transaction.internal.TimedOutException: Transaction timed out after 59 seconds
    Xid=13474:af8a0fba65bcc42e(5631273),Status=Active (PrePreparing),numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=59,seconds left=60,activeThread=Thread[ExecuteThread: '10' for queue: 'default',5,Thread Group for Queue: 'default'],SCInfo[edisdomain+edisServer]=(state=pre-preparing),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=edisServer+160.129.51.156:2206+edisdomain+, Resources={})],CoordinatorURL=edisServer+160.129.51.156:2206+edisdomain+)
         at weblogic.transaction.internal.ServerTransactionImpl.wakeUp(ServerTransactionImpl.java:1121)
         at weblogic.transaction.internal.ServerTransactionManagerImpl.processTimedOutTransactions(ServerTransactionManagerImpl.java:466)
         at weblogic.transaction.internal.TransactionManagerImpl.wakeUp(TransactionManagerImpl.java:1604)
         at weblogic.transaction.internal.ServerTransactionManagerImpl.wakeUp(ServerTransactionManagerImpl.java:429)
         at weblogic.transaction.internal.TransactionManagerImpl$1.run(TransactionManagerImpl.java:1570)
         at java.lang.Thread.run(Thread.java:479)
    --------------- nested within: ------------------
    weblogic.transaction.RollbackException: Transaction timed out after 59 seconds
    Xid=13474:af8a0fba65bcc42e(5631273),Status=Active (PrePreparing),numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=59,seconds left=60,activeThread=Thread[ExecuteThread: '10' for queue: 'default',5,Thread Group for Queue: 'default'],SCInfo[edisdomain+edisServer]=(state=pre-preparing),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=edisServer+160.129.51.156:2206+edisdomain+, Resources={})],CoordinatorURL=edisServer+160.129.51.156:2206+edisdomain+) - with nested exception:
    [weblogic.transaction.internal.TimedOutException: Transaction timed out after 59 seconds
    Xid=13474:af8a0fba65bcc42e(5631273),Status=Active (PrePreparing),numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=59,seconds left=60,activeThread=Thread[ExecuteThread: '10' for queue: 'default',5,Thread Group for Queue: 'default'],SCInfo[edisdomain+edisServer]=(state=pre-preparing),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=edisServer+160.129.51.156:2206+edisdomain+, Resources={})],CoordinatorURL=edisServer+160.129.51.156:2206+edisdomain+)]
         at weblogic.transaction.internal.TransactionImpl.throwRollbackException(TransactionImpl.java:1481)
         at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:262)
         at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:189)
         at weblogic.transaction.internal.TransactionManagerImpl.commit(TransactionManagerImpl.java:247)
         at weblogic.transaction.internal.TransactionManagerImpl.commit(TransactionManagerImpl.java:240)
         at oracle.toplink.jts.JTSExternalTransactionController.commitTransaction(Unknown Source)
         at oracle.toplink.publicinterface.Session.commitExternalTransaction(Unknown Source)
         at oracle.toplink.publicinterface.UnitOfWork.commitInternallyStartedExternalTransaction(Unknown Source)
         at oracle.toplink.publicinterface.UnitOfWork.commit(Unknown Source)
         at vanderbilt.ed.stats.data.StatsCollectorDAO.updateCurrWbStats(StatsCollectorDAO.java:127)
         at vanderbilt.ed.stats.WbStatsDelegate.updateCurrWbStats(WbStatsDelegate.java:79)
         at vanderbilt.ed.stats.ejb.EdisStatsBean.onMessage(EdisStatsBean.java:147)
         at weblogic.ejb20.internal.MDListener.execute(MDListener.java:262)
         at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:214)
         at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:1865)
         at weblogic.jms.client.JMSSession.execute(JMSSession.java:1819)
         at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
         at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
    ####<Aug 3, 2003 4:05:18 PM CDT> <Error> <EDWhiteboard> <vumcportal1> <edisServer> <ExecuteThread: '10' for queue: 'default'> <guest> <> <000000> <EdisStatsBean: updateCurrWbStats(): DataAccessException
    EXCEPTION DESCRIPTION: Exception occurred within JTS.
    INTERNAL EXCEPTION: weblogic.transaction.RollbackException: Transaction timed out after 59 seconds
    Xid=13474:af8a0fba65bcc42e(5631273),Status=Active (PrePreparing),numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=59,seconds left=60,activeThread=Thread[ExecuteThread: '10' for queue: 'default',5,Thread Group for Queue: 'default'],SCInfo[edisdomain+edisServer]=(state=pre-preparing),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=edisServer+160.129.51.156:2206+edisdomain+, Resources={})],CoordinatorURL=edisServer+160.129.51.156:2206+edisdomain+) - with nested exception:
    [weblogic.transaction.internal.TimedOutException: Transaction timed out after 59 seconds
    Xid=13474:af8a0fba65bcc42e(5631273),Status=Active (PrePreparing),numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=59,seconds left=60,activeThread=Thread[ExecuteThread: '10' for queue: 'default',5,Thread Group for Queue: 'default'],SCInfo[edisdomain+edisServer]=(state=pre-preparing),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=edisServer+160.129.51.156:2206+edisdomain+, Resources={})],CoordinatorURL=edisServer+160.129.51.156:2206+edisdomain+)]>
    vanderbilt.ed.dao.DataAccessException: DataAccessException
    EXCEPTION DESCRIPTION: Exception occurred within JTS.
    INTERNAL EXCEPTION: weblogic.transaction.RollbackException: Transaction timed out after 59 seconds
    Xid=13474:af8a0fba65bcc42e(5631273),Status=Active (PrePreparing),numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=59,seconds left=60,activeThread=Thread[ExecuteThread: '10' for queue: 'default',5,Thread Group for Queue: 'default'],SCInfo[edisdomain+edisServer]=(state=pre-preparing),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=edisServer+160.129.51.156:2206+edisdomain+, Resources={})],CoordinatorURL=edisServer+160.129.51.156:2206+edisdomain+) - with nested exception:
    [weblogic.transaction.internal.TimedOutException: Transaction timed out after 59 seconds
    Xid=13474:af8a0fba65bcc42e(5631273),Status=Active (PrePreparing),numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=59,seconds left=60,activeThread=Thread[ExecuteThread: '10' for queue: 'default',5,Thread Group for Queue: 'default'],SCInfo[edisdomain+edisServer]=(state=pre-preparing),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=edisServer+160.129.51.156:2206+edisdomain+, Resources={})],CoordinatorURL=edisServer+160.129.51.156:2206+edisdomain+)]
         at vanderbilt.ed.stats.data.StatsCollectorDAO.updateCurrWbStats(StatsCollectorDAO.java:135)
         at vanderbilt.ed.stats.WbStatsDelegate.updateCurrWbStats(WbStatsDelegate.java:79)
         at vanderbilt.ed.stats.ejb.EdisStatsBean.onMessage(EdisStatsBean.java:147)
         at weblogic.ejb20.internal.MDListener.execute(MDListener.java:262)
         at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:214)
         at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:1865)
         at weblogic.jms.client.JMSSession.execute(JMSSession.java:1819)
         at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
         at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
    ####<Aug 3, 2003 4:05:18 PM CDT> <Error> <EDWhiteboard> <vumcportal1> <edisServer> <ExecuteThread: '10' for queue: 'default'> <guest> <> <000000> <EdisStatsBean:onMessage():vanderbilt.ed.dao.DataAccessException: DataAccessException DataAccessException
    EXCEPTION DESCRIPTION: Exception occurred within JTS.
    INTERNAL EXCEPTION: weblogic.transaction.RollbackException: Transaction timed out after 59 seconds
    Xid=13474:af8a0fba65bcc42e(5631273),Status=Active (PrePreparing),numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=59,seconds left=60,activeThread=Thread[ExecuteThread: '10' for queue: 'default',5,Thread Group for Queue: 'default'],SCInfo[edisdomain+edisServer]=(state=pre-preparing),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=edisServer+160.129.51.156:2206+edisdomain+, Resources={})],CoordinatorURL=edisServer+160.129.51.156:2206+edisdomain+) - with nested exception:
    [weblogic.transaction.internal.TimedOutException: Transaction timed out after 59 seconds
    Xid=13474:af8a0fba65bcc42e(5631273),Status=Active (PrePreparing),numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=59,seconds left=60,activeThread=Thread[ExecuteThread: '10' for queue: 'default',5,Thread Group for Queue: 'default'],SCInfo[edisdomain+edisServer]=(state=pre-preparing),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=edisServer+160.129.51.156:2206+edisdomain+, Resources={})],CoordinatorURL=edisServer+160.129.51.156:2206+edisdomain+)] DataAccessException DataAccessException
    EXCEPTION DESCRIPTION: Exception occurred within JTS.
    INTERNAL EXCEPTION: weblogic.transaction.RollbackException: Transaction timed out after 59 seconds
    Xid=13474:af8a0fba65bcc42e(5631273),Status=Active (PrePreparing),numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=59,seconds left=60,activeThread=Thread[ExecuteThread: '10' for queue: 'default',5,Thread Group for Queue: 'default'],SCInfo[edisdomain+edisServer]=(state=pre-preparing),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=edisServer+160.129.51.156:2206+edisdomain+, Resources={})],CoordinatorURL=edisServer+160.129.51.156:2206+edisdomain+) - with nested exception:
    [weblogic.transaction.internal.TimedOutException: Transaction timed out after 59 seconds
    Xid=13474:af8a0fba65bcc42e(5631273),Status=Active (PrePreparing),numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=59,seconds left=60,activeThread=Thread[ExecuteThread: '10' for queue: 'default',5,Thread Group for Queue: 'default'],SCInfo[edisdomain+edisServer]=(state=pre-preparing),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=edisServer+160.129.51.156:2206+edisdomain+, Resources={})],CoordinatorURL=edisServer+160.129.51.156:2206+edisdomain+)]>
    vanderbilt.ed.dao.DataAccessException: DataAccessException DataAccessException
    EXCEPTION DESCRIPTION: Exception occurred within JTS.
    INTERNAL EXCEPTION: weblogic.transaction.RollbackException: Transaction timed out after 59 seconds
    Xid=13474:af8a0fba65bcc42e(5631273),Status=Active (PrePreparing),numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=59,seconds left=60,activeThread=Thread[ExecuteThread: '10' for queue: 'default',5,Thread Group for Queue: 'default'],SCInfo[edisdomain+edisServer]=(state=pre-preparing),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=edisServer+160.129.51.156:2206+edisdomain+, Resources={})],CoordinatorURL=edisServer+160.129.51.156:2206+edisdomain+) - with nested exception:
    [weblogic.transaction.internal.TimedOutException: Transaction timed out after 59 seconds
    Xid=13474:af8a0fba65bcc42e(5631273),Status=Active (PrePreparing),numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=59,seconds left=60,activeThread=Thread[ExecuteThread: '10' for queue: 'default',5,Thread Group for Queue: 'default'],SCInfo[edisdomain+edisServer]=(state=pre-preparing),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=edisServer+160.129.51.156:2206+edisdomain+, Resources={})],CoordinatorURL=edisServer+160.129.51.156:2206+edisdomain+)]
         at vanderbilt.ed.stats.WbStatsDelegate.updateCurrWbStats(WbStatsDelegate.java:86)
         at vanderbilt.ed.stats.ejb.EdisStatsBean.onMessage(EdisStatsBean.java:147)
         at weblogic.ejb20.internal.MDListener.execute(MDListener.java:262)
         at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:214)
         at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:1865)
         at weblogic.jms.client.JMSSession.execute(JMSSession.java:1819)
         at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
         at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
    ####<Aug 3, 2003 4:05:23 PM CDT> <Info> <JDBC> <vumcportal1> <edisServer> <ExecuteThread: '4' for queue: 'default'> <guest> <> <001068> <Connection for pool "oraclePool" created.>
    ####<Aug 3, 2003 4:05:23 PM CDT> <Info> <EDWhiteboard> <vumcportal1> <edisServer> <ExecuteThread: '9' for queue: 'CriticalAppQueue'> <> <> <000000> <CliniciansOnDuty:getNurseLookUpList IS NULL>
    ####<Aug 3, 2003 4:05:26 PM CDT> <Info> <JDBC> <vumcportal1> <edisServer> <ExecuteThread: '15' for queue: 'CriticalAppQueue'> <> <> <001068> <Connection for pool "oraclePool" created.>
    ####<Aug 3, 2003 4:05:26 PM CDT> <Info> <EDWhiteboard> <vumcportal1> <edisServer> <ExecuteThread: '7' for queue: 'default'> <system> <> <000000> <END: EDEncounterDAO:getEdAndWaitingRoomdata(): SUCCESSFUL>
    ####<Aug 3, 2003 4:05:28 PM CDT> <Info> <JDBC> <vumcportal1> <edisServer> <ExecuteThread: '16' for queue: 'CriticalAppQueue'> <> <> <001068> <Connection for pool "oraclePool" created.>
    ####<Aug 3, 2003 4:05:28 PM CDT> <Info> <EDWhiteboard> <vumcportal1> <edisServer> <ExecuteThread: '14' for queue: 'CriticalAppQueue'> <> <> <000000> <CliniciansOnDuty:getNurseLookUpList IS NULL>
    ####<Aug 3, 2003 4:05:34 PM CDT> <Error> <EDWhiteboard> <vumcportal1> <edisServer> <ExecuteThread: '4' for queue: 'default'> <guest> <> <000000> <WhiteboardServerDAO:updatePatient() 9 : Update ERROR: 8

    Actually, what one or the developers in my group found out is two things:
    1) The clone is a shallow copy.They copy the references but not objects themselves. This has been causing problems for us.
    2) It seems that you don't work on a copy and you work on the original and they keep a copy. Now, this is fine IF you don't have multiple threads working on the same Entity bean and we moved our application from Weblogic where it throws an exception if that Entity bean is in use to OC4J which is suppose to copy the bean and doesn't so you have multiple threads possibly modifying the same object.

  • JMS timeout and redelivery

    I have two simple questions:
    1. Let's suppose a situation when a table lock is present in our database and the MDB regularly runs into this lock every time when the onMessage method is called. It always reserves a new MDB because the MDB created by the previous call is not capable to move back to the pool becaus of the lock. It means if there is no more free bean in the pool a new bean will be created. Hence a simple database lock can cause application server to run out of system resources.
    Is there any way to catch the timeout or how can I avoid this situation?
    2. If consumption of the message fails the message is redelivered successively but the reason of the failure is still present. I wouldn't like to lose these failed messages. Do I have to move these to another queue or is there any standard scenario for this kind of situation? Can I delay the redelivery?
    Thanks in advance

    To the second question, it is dependant of your JMS providers. It may include these configuration parameters to fine-tune redelivery:
    * Redelivery count: The number of times to redeliver a message. Redelivery count is important because poison messages, messages the application can never successfully process, can eventually crash the system.
    * Exception destination: What happens to a message that is redelivered redelivery-count times? The JMS provider can do any of the following:
    o Log the message
    o Forward the message to an exception or error destination
    o Lose the message
    * Time to redeliver: An application that has just rolled back messages might not be ready to reprocess the same messages. This parameter specifies the time to wait before redelivering the message. This delay lets the JMS provider and the application recover to a stable state.
    I know that in weblogic, you can specify this parameters when you specify your JMS settings.
    Actually I work with BES 5.2.1, and I can not specify this settings. It will be a new feature of BES 6.

  • JMS time-out

    Hi, could anyone tell me what exactly means time-out for JMS? Does JMS has time-out concept? If any, what does it time out, session or connection?
    Thanks

    Hi,
    JMS Timeout has nothing to do with Session Timeout or connection timeout.Concept is same.
    Application server waits till the message is delivered and within some time if it doen't get the response, it times out.
    I hope u understood this.

  • Cannot retrieve data in all members of my distributed queue

    I have a distributed queue with 3 members, queue member 1, queue member 2, and queue member 3.
    I triggered 2 events separately to go to the distributed queue, and it was successful as the 1st event triggered went to queue member 1 (physical queue1 – located on server 1) and the next event sent on the next trigger went to queue member 2 (physical queue 2 – located on server 2).
    The problem now is, after triggering a job that gets the event from distributed queue, only the event in queue member 1 was picked up. The job got completed without picking up the event in queue member 2 (different VM). The data in queue member 2 was left. The config file for the JMS Queue Connectivity may be seen below:
    jms.url=t3://<MS1_IP>:<MS1_PORT>,<MS2_IP>:<MS2_PORT>,<MS3_IP>:<MS3_PORT>
    jms.connfactory=ConnFactoryName
    jms.timeout=30000
    jms.queue=DistributedQueueName
    Note also that the connection factory is deployed to all managed servers as I could see the connection factory in the jndi tree of each managed server.
    Our job was able to get data from each of the managed server, one by one. An example I tried is I placed an event in queue member 1 then triggered the job, then the data was picked up. Then next, I placed the data in queue member 2 (with no other data in queue member 1 and 3), then the data in queue member 2 was picked up after the job run, and same when placed only in queue member 3.
    The main problem here is when there are data in all of the physical queues (queue member 1 to 3). As if the application is focused only to one physical queue, which shouldn’t be. Researching now how should it read all the members in the distributed queue.

    Hi,
    A comma separated URL list helps a client setup its initial JNDI connection into the cluster - it doesn't directly control load balancing of future JEE EJB, RMI, or JMS calls. By default, for remote clients, JEE calls will automatically load balance a new direct connection randomly among all servers in the cluster, even if the initial JNDI URL only references a single server's address. It's actually not truly random, as there may be internal heuristics that effect the load balance decision, plus the behavior is actually tunable, but, for almost all use cases, its best to stay with the default behavior and think of it as effectively random.
    WebLogic JMS load-balancing actually occurs at three layers: URL/DNS, "smart stub" connection creation (RMI, EJB, and JMS connection factory), and finally the distributed destination layers. For a full end-to-end explanation of load balancing at the different layers of the WL stack, I highly recommend the JMS chapter of the book "Professional Oracle WebLogic".
    What's happening in your case is that JMS individual consumer always load balances to one particular queue member, and then sticks to that queue member for their lifetime. This is expected behavior for consumer load balancing, and is fully documented in the distributed destination documention of the JMS programmer's guide.
    If you want to ensure full coverage of a distributed queue, in order of highest to lowest preference:
    * Most highly recommend: Use a WL MDB or a 11gR1PS3 SOA Adapter (if you happen to be using Oracle's SOA layered product). These automatically ensure that all distributed queue members are serviced by at least one dedicated consumer.
    * Ensure you have more sessions+consumers than queue members. Periodically refresh connections/sessions/consumers in order to ensure that newly started members are serviced even when all consumers are already connected (eg, code your clients to reconnect every few minutes).
    * If your application is not performance sensitive, configure the "queue forward delay" setting on a distributed queue. Messages that are trapped on a queue member with no consumers for longer than this delay will be automatically forwarded a member that has consumers.
    * Least recommended, very advanced usage only: Code clients to use the new 10.3.4 public "destination availability" extensions. These extension APIs provide a notification service for distributed destination member up/down events.
    Regards,
    Tom

  • Problem with transacted JMS connection factory and transaction timeouts

              We encountered an interesting problem using transacted JMS connection factories.
              An EJB starts a container managed transaction and tries to validate a credit card
              before creating some information to a database for the user, in case of success
              an SMS is sent to the user via the transacted JMS queue. If the credit card authentications
              duration is about the same as the transactions timeout (in this case the default
              30 seconds) sometimes the database inserts is committed but the JMS insert is
              rollbacked. How can this be?
              If the authorization duration is much longer than 30 seconds everything works
              fine (both database and JMS inserts rollbacked), the same is true if a rollback
              is insured by calling EJBContext.setRollbackOnly(). The problem thus occurs only
              if the duration is approximately the same as the transaction timeout, it appears
              that the database insert is not timeouted but the JMS insert is. How can this
              be if they are both participating in the same transaction.
              The JMSConnectionFactory used is a Connection factory with XA-enabled. The result
              is the same also with the default "javax.jms.QueueConnectionFactory" and if we
              configure our own factory with user transactions enabled.
              Any help appreciated!
              

    Tomas Granö wrote:
              > We encountered an interesting problem using transacted JMS connection factories.
              > An EJB starts a container managed transaction and tries to validate a credit card
              > before creating some information to a database for the user, in case of success
              > an SMS is sent to the user via the transacted JMS queue. If the credit card authentications
              > duration is about the same as the transactions timeout (in this case the default
              > 30 seconds) sometimes the database inserts is committed but the JMS insert is
              > rollbacked. How can this be?
              It should not be.
              >
              > If the authorization duration is much longer than 30 seconds everything works
              > fine (both database and JMS inserts rollbacked), the same is true if a rollback
              > is insured by calling EJBContext.setRollbackOnly(). The problem thus occurs only
              > if the duration is approximately the same as the transaction timeout, it appears
              > that the database insert is not timeouted but the JMS insert is. How can this
              > be if they are both participating in the same transaction.
              >
              > The JMSConnectionFactory used is a Connection factory with XA-enabled. The result
              > is the same also with the default "javax.jms.QueueConnectionFactory" and if we
              > configure our own factory with user transactions enabled.
              >
              > Any help appreciated!
              Make sure that your session is not "transacted". In other words,
              the first parameter to createSession() must be false. There is an
              unfortunate name re-use here. If a session is "transacted", it
              maintains an independent "inner transaction" independent of the
              outer transaction. From the above description, it seems unlikely
              that your application has this wrong, as you say that
              "setRollbackOnly" works - but please check anyway.
              Make sure that you are using a true XA capable driver and database
              (XA "emulation" may not suffice)
              Beyond the above, I do not see what can be going wrong. You
              may want to try posting to the transactions and jdbc newsgroups. Note
              that JMS is appears to be exhibiting the correct behavior, but the
              JDBC operation is not. The JDBC operation appears to have
              its timeout independent of the transaction monitor's timeout.
              Tom
              

  • Can any help on JMS topic timeout issue

    Hi ,
              I am getting following error while reading the messages from JMS queue, can any one help me what time out setting i need to increase at console.
              Thanks in advance
              2005-11-03 05:02:36,839 ERROR ExecuteThread: '2' for queue: 'default' - Remote problem accessing topic
              weblogic.jms.common.LostServerException: weblogic.rjvm.PeerGoneException: ; nested exception is:
              java.io.IOException: A complete message could not be read on socket: 'weblogic.rjvm.t3.T3JVMConnection@6545d2', in th
              e configured timeout period of '60' secs
              at weblogic.jms.client.JMSConnection.jmsPeerGone(JMSConnection.java:917)
              at weblogic.jms.dispatcher.DispatcherWrapperState.peerGone(DispatcherWrapperState.java:703)
              at weblogic.jms.dispatcher.DispatcherWrapperState.callback(DispatcherWrapperState.java:562)
              at weblogic.rjvm.RJVMImpl$HeartbeatMonitorListenerDeliverer.execute(RJVMImpl.java:1554)
              at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
              at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
              2005-11-03 05:02:36,843 ERROR ExecuteThread: '2' for queue: 'default' - Lost server, shutting down.
              weblogic.jms.common.LostServerException: weblogic.rjvm.PeerGoneException: ; nested exception is:
              java.io.IOException: A complete message could not be read on socket: 'weblogic.rjvm.t3.T3JVMConnection@6545d2', in th
              e configured timeout period of '60' secs
              at weblogic.jms.client.JMSConnection.jmsPeerGone(JMSConnection.java:917)
              at weblogic.jms.dispatcher.DispatcherWrapperState.peerGone(DispatcherWrapperState.java:703)
              at weblogic.jms.dispatcher.DispatcherWrapperState.callback(DispatcherWrapperState.java:562)
              at weblogic.rjvm.RJVMImpl$HeartbeatMonitorListenerDeliverer.execute(RJVMImpl.java:1554)
              at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
              at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
              thanks,
              kiran

    Bunney:
    It is assumed at this point that the report script you use in essbase does NOT contain the greater than signs that the forum inserts.
    As I suggested on your other thread and Glenn has suggested here, the first step is to prototype an excel retrieval and then convert that retrieval into a report script.
    What is not well known by many is that you can use a report script inside excel too. All you need to do is go to the mode tab within essbase options and select free form instead of advanced interpretation (you'll want to revert it back for normal use). In free form mode, the report script can be used in a spreadsheet.
    Of course, the whole idea is to create the normal template that retrieves data, and then create the report script equivalent. So, the idea of using free form is just a way to help verify that you don't have an issue with the report engine itself.

  • JMS Adapter timeout property

    How do I set timeout property for JMS adapter in BPEL in SOA Suite 10g ?
    Scenario :
    In one of the business scenarios, a JMS message in enqueued to WebLogic JMS queue from BPEL process.
    There is a asyncronus invoke activity to the JMS adapter partner link.
    This invoke activity to the JMS adapter took 15 mins in one of the invocations and hence giving timeout to the bpel client.
    Query :
    Is there any way I could set the timeout for this invocation, either at partner link level or a JMS adapter connection factory level.

    Hi,
    This is supposed to solve ERRJMS_PROVIDER_ERR error for JMS adapter.
    Please refer metalink NOTE:393468.1.
    I am not sure if it works for 10.1.2.0.2 version but probably it works on 10.1..3.X version.
    Regards,
    Ved

  • Jms receive timeout problem

    Hi guys,
    I want to receive messages on a timeout basis. However, my code always stuck at a certain point. Here is my source code:
    import javax.jms.*;
    import javax.naming.Context;
    import javax.naming.NamingException;
    import javax.naming.spi.NamingManager;
    import java.util.Hashtable;
    public class JmsRecv {
        public static void main(String[] args) throws JMSException, NamingException {
            Context JndiContext = createContextForWeblogic(args[0]);
            QueueConnectionFactory TheQueueConnectionFactory = (QueueConnectionFactory) JndiContext.lookup("weblogic.jms.ConnectionFactory");
            Queue q = (Queue) JndiContext.lookup("Queue_A");
            QueueConnection qc = TheQueueConnectionFactory.createQueueConnection();
            qc.start();
            QueueSession qs = qc.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
            QueueReceiver qr = qs.createReceiver(q, null);
            Message mrecv = null;
            long elapsed = 0;
            int index = 1;
            while (mrecv == null && elapsed < 200) {
                long start = System.currentTimeMillis();
                mrecv = qr.receive(10);
                elapsed = System.currentTimeMillis() - start;
                System.out.println("index=" + index++ + " elapsed=" + elapsed);
            qr.close();
            qs.close();
            qc.close();
        static Context createContextForWeblogic(String connectionURL) {
            Context ctx = null;
            Hashtable env = new Hashtable();
            env.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
            env.put(Context.PROVIDER_URL, connectionURL);
            try {
                ctx = NamingManager.getInitialContext(env);
            } catch (Exception e) {
                e.printStackTrace();
                MSFException msfException = new MSFException(e.getMessage());
                msfException.initCause(e);
                throw msfException;
            return ctx;
    }And the result is always:
    index=1 elapsed=31
    index=2 elapsed=16
    index=3 elapsed=15
    index=139 elapsed=16
    index=140 elapsed=15
    index=141 elapsed=9391
    It always stops at index 141. Why the jms receive with timeout works initially then doesn't work as expected? Any ideas?? I have a similar problem with send too. Send works quickly initially but at a certain point sending takes too much time. Thanks.
    Gurkan

    try moving
    long start = System.currentTimeMillis();
    outside your while loop. That is your starting point and it should change after you start. But having it in the loop resets it.

  • [svn:bz-trunk] 19362: Increase the tests' timeout since it takes about 17 sec for JMS server to start up on some app servers .

    Revision: 19362
    Revision: 19362
    Author:   [email protected]
    Date:     2010-12-14 08:16:35 -0800 (Tue, 14 Dec 2010)
    Log Message:
    Increase the tests' timeout since it takes about 17 sec for JMS server to start up on some app servers.
    Modified Paths:
        blazeds/trunk/qa/apps/qa-regress/testsuites/config/tests/uuidgeneration/CustomUUIDGenerat orTest/simpleJMSMessagingTest.mxml
        blazeds/trunk/qa/apps/qa-regress/testsuites/config/tests/uuidgeneration/DuplicateUUIDTest /DuplicateUUIDTest1.mxml

    check the server log;
    /app/oracle/product/fwm11g/user_projects/domains/fwm_domain/servers/AdminServer/logs/AdminServer.log
    you can launch the console and see if it is running; http://<server>:<port>/console

  • JTA timeout Weblogic (JMS)

    I have an MDB that reads from a queue quite big messages that are inserted in the database.
    So it's JMS + JDBC so I use JTA.
    On weblogic level I can specify the transaction timeout and set to 10,15 min. (i know is not a good practice for such long transactions but is legacy code)
    I still have worries regarding the JDBC and JMS configuration...: is the JTA overriding the configuration for JDBC or JMS transactions ?
    IF JDBC is configured for a shorter period to timeout ?
    I did not manages to read the specs to see how this should be generally done but i assume is particular from server to server...
    Thanks.

    This provides some information on configuring JTA - http://docs.oracle.com/cd/E21764_01/web.1111/e13731/trxcon.htm#i1054599
    and the administration tasks - http://docs.oracle.com/cd/E21764_01/web.1111/e13731/trxman.htm#i1053371

  • JDBC connection pool failures when used by JMS stores

              We are using WebLogic 6.1 sp2. We defined a separate connection pool for use by
              a JMS Store.
              <JDBCConnectionPool Name="sybaseJMSPool"
              Targets="cluster00"
              InitialCapacity="2"
              MaxCapacity="10"
              DriverName="com.sybase.jdbc2.jdbc.SybDriver"
              Properties="[email protected]@;[email protected]@;charset=utf8"
              URL="jdbc:sybase:Tds:@jms.db.host@/@jms.db.name@"/>
              (note that the @xxx@ string are replaced by actual values).
              We are using Sybase Jconnect 5.5 to a Sybase ASE 12.5 database.
              We deployed this configuration on a number of environments (testing, staging,
              ..). The actual hardware and network configuration is different for the different
              system, but the WebLogic domain stays the same regarding this issue.
              On the test system we frequently get the following exceptions:
              <Aug 13, 2002 1:56:04 PM CEST> <Alert> <JMS> <www00-test> <node00>
              <ExecuteThread: '6' for queue: 'JMS.TimerClientPool'> <> <> <040048>
              <JMSServer "JMSServer00", store failure while writing message for topic
              OrderChangeTopic, java.io.IOException: JMS JDBC store, connection pool =
              <sybaseJMSPool>, prefix = <JMS00>: write failed
              java.sql.SQLException: JZ006: Caught IOException:
              com.sybase.jdbc2.jdbc.SybConnectionDeadException: JZ0C0: Connection is already
              closed.
              at com.sybase.jdbc2.jdbc.ErrorMessage.raiseErrorCheckDead
              (ErrorMessage.java:715)
              at com.sybase.jdbc2.tds.Tds.handleIOE(Tds.java:3124)
              at com.sybase.jdbc2.tds.Tds.cancel(Tds.java:1412)
              at com.sybase.jdbc2.tds.Tds.cancel(Tds.java:1341)
              at com.sybase.jdbc2.jdbc.SybStatement.doCancel(SybStatement.java:564)
              at com.sybase.jdbc2.jdbc.SybStatement.updateLoop(SybStatement.java:1672)
              at com.sybase.jdbc2.jdbc.SybStatement.executeUpdate
              (SybStatement.java:1625)
              at com.sybase.jdbc2.jdbc.SybPreparedStatement.executeUpdate
              (SybPreparedStatement.java:91)
              at com.p6spy.engine.logging.P6LogPreparedStatement.executeUpdate
              (P6LogPreparedStatement.java:179)
              at weblogic.jdbc.pool.Statement.executeUpdate(Statement.java:293)
              at weblogic.jms.store.JDBCIOStream.write(JDBCIOStream.java:1246)
              at weblogic.jms.store.StoreRequest.doTheIO(StoreRequest.java:250)
              at weblogic.jms.store.JMSStore.execute(JMSStore.java:182)
              at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
              at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
              .>
              java.io.IOException: JMS JDBC store, connection pool = <sybaseJMSPool>, prefix
              = <JMS00>: write failed
              java.sql.SQLException: JZ006: Caught IOException:
              com.sybase.jdbc2.jdbc.SybConnectionDeadException: JZ0C0: Connection is already
              closed.
              at com.sybase.jdbc2.jdbc.ErrorMessage.raiseErrorCheckDead
              (ErrorMessage.java:715)
              at com.sybase.jdbc2.tds.Tds.handleIOE(Tds.java:3124)
              at com.sybase.jdbc2.tds.Tds.cancel(Tds.java:1412)
              at com.sybase.jdbc2.tds.Tds.cancel(Tds.java:1341)
              at com.sybase.jdbc2.jdbc.SybStatement.doCancel(SybStatement.java:564)
              at com.sybase.jdbc2.jdbc.SybStatement.updateLoop(SybStatement.java:1672)
              at com.sybase.jdbc2.jdbc.SybStatement.executeUpdate
              (SybStatement.java:1625)
              at com.sybase.jdbc2.jdbc.SybPreparedStatement.executeUpdate
              (SybPreparedStatement.java:91)
              at com.p6spy.engine.logging.P6LogPreparedStatement.executeUpdate
              (P6LogPreparedStatement.java:179)
              at weblogic.jdbc.pool.Statement.executeUpdate(Statement.java:293)
              at weblogic.jms.store.JDBCIOStream.write(JDBCIOStream.java:1246)
              at weblogic.jms.store.StoreRequest.doTheIO(StoreRequest.java:250)
              at weblogic.jms.store.JMSStore.execute(JMSStore.java:182)
              at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
              at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
              at weblogic.jms.store.JDBCIOStream.throwIOException
              (JDBCIOStream.java:1213)
              at weblogic.jms.store.JDBCIOStream.write(JDBCIOStream.java:1256)
              at weblogic.jms.store.StoreRequest.doTheIO(StoreRequest.java:250)
              at weblogic.jms.store.JMSStore.execute(JMSStore.java:182)
              at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
              at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
              Before that this message appeared:
              <Aug 13, 2002 11:31:16 AM CEST> <Error> <ConnectionManager> <www00-test>
              <node00> <ExecuteThread: '26' for queue: 'default'> <> <> <000000>
              <Closing: 'weblogic.rjvm.t3.T3JVMConnection@795af6' because of: 'Server
              received a message over an uninitialized connection: 'JVMMessage from: 'null'
              to: '-4555218188801970213S:192.168.13.1:[7001,7001,7002,7002,7001,7002,-
              1]:ADIS:node00' cmd: 'CMD_REQUEST', QOS: '101', responseId: '1',
              invokableId: '287', flags: 'JVMIDs Not Sent, TX Context Not Sent', abbrev
              offset: '34'''>
              This problem did not occur on another system which was used during a 2 day stress
              testing session.
              It seems that the problem occurs after a period in which no user request where
              made. The user requests trigger EJB's that start sending JMS messages.
              When the problem occurs, the JMS messaging systems seems to lock up as no messages
              are received anymore by the different listeners (MDBs).
              Undeploying and redeploying the JBDC connection pool solves the problem. This
              solution is unacceptable in case of a production system.
              A similarly defined connection pool, which is used by the EJBs to make database
              connection, does not manifest this problem.
              <JDBCConnectionPool Name="sybasePool"
              Targets="cluster00"
              InitialCapacity="10"
              CapacityIncrement="5"
              MaxCapacity="50"
              PreparedStatementCacheSize="150"
              DriverName="com.sybase.jdbc2.jdbc.SybDriver"
              Properties="[email protected]@;[email protected]@;JCONNECT_VERSION=6;charset=utf8"
              URL="jdbc:sybase:Tds:@db.host@/@db.name@"/>
              The JDBC connection pool is used as follows by the JDBC store
              <JMSJDBCStore ConnectionPool="sybaseJMSPool" Name="JDBCStore00" PrefixName="JMS00"/>
              <JMSServer Name="JMSServer00" Store="JDBCStore00" Targets="node00">
              <JMSTopic JNDIName="ADIS.JMSError" JNDINameReplicated="false" Name="ErrorTopic"/>
              <JMSTopic JNDIName="ADIS.Status"
              Name="StatusTopic" RedeliveryDelayOverride="300000"/>
              <JMSTopic JNDIName="ADIS.OrderChange" JNDINameReplicated="false"
              Name="OrderChangeTopic" RedeliveryLimit="3"/>
              </JMSServer>
              Turning on the "Test Reserved Connection" with a appropriate test table does not
              help.
              Some sources on the internet tell us that JZ0C0 errors in the Jconnect driver
              can be related to network problems. Nevertheless the connection pool should be
              able to cope with this.
              Can you provide any solution for this ? Or give us hints what can cause the problem
              

    Zhenhao Qi wrote:
    thanks! Joe.
    The SQL statement itself can no longer be simplified, the long excuation time is due to the database size and complicated Select criteria. I can easily reproduce the problem by using this SQL. I tried "BEA's Oracle driver (Type 4): Version 8.1.7,9.0.1,9.2.0". the question can be dissect into 2 pieces:
    1) why the jdbc connection (using oracle.jdbc.OracleDriver) won't return anything if the SQL execution time > 5min, that is probably the Oracle's problem
    2) why the occupied connection pool won't release even I set "Statementtimeout=600", this is Weblogic's problem.
    ZhenhaoHi. Yes, (1) is oracle's problem. (2) may also be. The JDBC spec has very few
    allowances for one thread to interrupt a second thread's JDBC call. If we
    transmit your timeout request by calling setQueryTimeout() on the oracle
    statement, and if you have a weblogic-controlled transaction we call
    Statement.cancel() on any ongoing statement, we end up relying on whether
    the Oracle driver implements and responds to those calls.
    Are you doing weblogic-controlled transactions? Are you/can you
    call Statement.setQueryTimeout() on your statements, or are these
    generated JDBC queries?
    If you can duplicate the problem using the weblogic.jdbc.oracle.OracleDriver
    we have some other debug avenues. This would be good even if you really
    want to use the thin driver, because we will do the same JDBC calls to
    either driver, and the debug would prove (if) we set up a query timeout
    and if we call cancel(). If we do, then we can know that it is the Oracle
    driver failing in these regards.
    Joe

  • Get data from a JMS XML queue and save it in a file

    Hi,
    Here I come with my issue again.
    I'm trying to test a JMS XML implementation with ODI 10.1.3.4.0 and my target is a single delimited file.
    I made simple things, my XML contains the following code :
    +<?xml version="1.0" encoding="UTF-8"?>+
    +<test><id>456</id><value>789</value></test>+
    In the target file, I specified that I wanted a header line, the id and the value, separated by a tab.
    I send only one message, before executing the ODI interface or package. The queue is persistant. There's no problem from the queue, I manage to read JMS messages with a little program I made.
    The result is also simple : there's no data in the file (not even the header), though it's well created by ODI, and there's no error in the opertor, it's as everything went well.
    Here is the settings I did in ODI :
    Topology : JMS XML Queue config
    Name : JMSXML_TEST
    Technology : JMS XML Queue
    I've a user and password set.
    JNDI Auth : simple
    The user and password are the same as above.
    JNDI protocole : not defined
    JNDI Driver : org.jnp.interfaces.NamingContextFactory
    JNDI URL : jnp://localhost:1099/?re=test&d=<DTD_FILE>&s=JMSXML_TEST_SCH&JMS_DESTINATION=queue/TestQueue1
    The connection test is OK.
    Model
    The JMS XML model is reversed from the DTD.
    There is only one datastore named TEST with an ID and VALUE columns, and other columns usefull to ODI.
    The target is a file represented by a datastore also named TEST with ID and VALUE columns.
    Project
    I created an interface with the following configurations :
    - The staging area is the sunopsis engine,
    - The source datastore and target datastore are the two described above,
    - The LKM is JMS XML to SQL, the IKM is SQL to File Append
    - The JMS_COMMIT option is set to yes
    - The SYNCHRO_JMS_TO_XML is set to yes
    - I added manually a NEXTMESSAGETIMEOUT in the options list because it was missing
    - The IKM settings are all set to yes (INSERT, TRUNCATE, GENERATE_HEADER).
    I also created a package containing this interface.
    Everything is done in the global context.
    Everything is installed locally on my computer : the program sending the messages, the JMS provider and ODI.
    The problem is I don't know where the problem is and neither ODI.
    In the operator, there is 0 insert and the error code is 0.
    Thanks in advance for any insights.
    Marie
    Edited by: Marie123456 on 21 août 2012 10:36

    Hi,
    Since I still have problems on this subject, I would like to share on how it progresses.
    Currently I have a problem of timeout in step "Truncate XML Schema" with the URL that I mentioned above.
    The exact error is the following : 7000 : null : com.sunopsis.sql.l: Oracle Data Integrator TimeOut : connection with URL [...]
    The connection test is still OK.
    I tried to increase the value in the user's pref but there's no change.

  • Embedded JMS/OC4J issue while running an application in Jdeveloper 10.1.3.2

    Hi,
    I am facing an issue while running an application on my laptop.I downloaded Jdeveloper 10.1.3.2.Installed Jheadstart along with that.
    Created a new application specified in HR demo.When I run the application I get following messages,After that it does not show my application pages.It does not even open browser window.
    [waiting for the server to complete its initialization...]
    Aug 29, 2007 6:01:47 PM com.evermind.server.jms.JMSMessages log
    INFO: JMSServer[]: OC4J JMS server recovering transactions (commit 0) (rollback 0) (prepared 0).
    Aug 29, 2007 6:01:47 PM com.evermind.server.jms.JMSMessages log
    INFO: JMSServer[]: OC4J JMS server recovering local transactions Queue[jms/Oc4jJmsExceptionQueue].
    07/08/29 18:01:55 Oracle Containers for J2EE 10g (10.1.3.1.1) initialized
    When I delete persistnce directory files under embedded oc4j (specifically jms.state), It logs following messages.But it does not run my application pages and not even open browser window to display some error.
    [Starting OC4J using the following ports: HTTP=8988, RMI=23891, JMS=9227.]
    C:\jdevstudio10132\jdev\system\oracle.j2ee.10.1.3.40.66\embedded-oc4j\config>
    C:jdevstudio10132\jdk\bin\javaw.exe -client -classpath C:jdevstudio10132\j2ee\home\oc4j.jar;C:jdevstudio10132\jdev\lib\jdev-oc4j-embedded.jar -Xverify:none -XX:MaxPermSize=256m -DcheckForUpdates=adminClientOnly -Doracle.application.environment=development -Doracle.j2ee.dont.use.memory.archive=true -Doracle.j2ee.http.socket.timeout=500 -Doc4j.jms.usePersistenceLockFiles=false oracle.oc4j.loader.boot.BootStrap -config C:\jdevstudio10132\jdev\system\oracle.j2ee.10.1.3.40.66\embedded-oc4j\config\server.xml
    [waiting for the server to complete its initialization...]
    07/08/29 18:06:16 Oracle Containers for J2EE 10g (10.1.3.1.1) initialized.
    I tried by creating another standalone application with simple html page, it throws same logs and does not show up browser window.I even tried with Jdeveloper 10.1.3.3, but still same issue .
    can you please throw some light on this issue and any suggestion for resolutions.
    Thanks.

    Can someone throw somelight on this issue?
    I posted the same issue in Jdeveloper forum but did not receive any reply .appreciate your suggestions.
    Thanks
    Sekar.

  • JMS/OC4J issue while running an application in Jdeveloper 10.1.3.2/10.1.3.3

    Hi,
    I am facing an issue while running an application on my laptop.I downloaded Jdeveloper 10.1.3.2.Installed Jheadstart along with that.
    Created a new application specified in HR demo.When I run the application I get following messages,After that it does not show my application pages.It does not even open browser window.
    [waiting for the server to complete its initialization...]
    Aug 29, 2007 6:01:47 PM com.evermind.server.jms.JMSMessages log
    INFO: JMSServer[]: OC4J JMS server recovering transactions (commit 0) (rollback 0) (prepared 0).
    Aug 29, 2007 6:01:47 PM com.evermind.server.jms.JMSMessages log
    INFO: JMSServer[]: OC4J JMS server recovering local transactions Queue[jms/Oc4jJmsExceptionQueue].
    07/08/29 18:01:55 Oracle Containers for J2EE 10g (10.1.3.1.1) initialized
    When I delete persistnce directory files under embedded oc4j (specifically jms.state), It logs following messages.But it does not run my application pages and not even open browser window to display some error.
    [Starting OC4J using the following ports: HTTP=8988, RMI=23891, JMS=9227.]
    C:\jdevstudio10132\jdev\system\oracle.j2ee.10.1.3.40.66\embedded-oc4j\config>
    C:jdevstudio10132\jdk\bin\javaw.exe -client -classpath C:jdevstudio10132\j2ee\home\oc4j.jar;C:jdevstudio10132\jdev\lib\jdev-oc4j-embedded.jar -Xverify:none -XX:MaxPermSize=256m -DcheckForUpdates=adminClientOnly -Doracle.application.environment=development -Doracle.j2ee.dont.use.memory.archive=true -Doracle.j2ee.http.socket.timeout=500 -Doc4j.jms.usePersistenceLockFiles=false oracle.oc4j.loader.boot.BootStrap -config C:\jdevstudio10132\jdev\system\oracle.j2ee.10.1.3.40.66\embedded-oc4j\config\server.xml
    [waiting for the server to complete its initialization...]
    07/08/29 18:06:16 Oracle Containers for J2EE 10g (10.1.3.1.1) initialized.
    I tried by creating another standalone application with simple html page, it throws same logs and does not show up browser window.I even tried with Jdeveloper 10.1.3.3, but still same issue .
    can you please throw some light on this issue and any suggestion for resolutions.
    Thanks.

    I am also facing the same issue on my laptop. I searched for forum but no luck.
    appreciate if anybody can throw some light on this.

Maybe you are looking for

  • Java threads consume CPU in sleep state (??)

    Hi, I'm using the PRSTAT command on Solaris for the first time. I am investigating high CPU usage problem in my application. So to monitor the CPU usage I used the prstat and mpstat command. My machine is a 2-CPU box. The prstat -L -p <pid> command o

  • About field in alv

    hello experts: how to make a field mandatory in alv. best regards, Kevin

  • Errors in While trying to Deopy Web Dynpro Application

    Hi,   I have NetWeaver 2004S in My local System. I am facing one problem while deploying that Web Dynpro Application from NWDS. Error is pasted below. But i can deploy EP Application. I am facing the same problem when i tried to Deploy from Remote GU

  • Change Selection Screen of S_ALR_87013531

    Hi Experts, I wants to put "Cost Element Group" in the selection screen of T-Code S_ALR_87013531. So what changes I shoud have to do in the program GP4BE3YM4TIC47TQLU2IP8XEAZ9. Thanks.

  • WLW 8.1.2 Upgrade Questions

    We have been running WL 8.1 (Workshop and Server) for the past several years. Development and production run on Windows 2000/XP Pro or Windows 2003 Server. We want to upgrade but do not want to prevent our ability to support current production system