About BEA WebLogic JMS on the cluster

Hi,
I have 3 files which together build in 1 EAR, then deploy on the cluster. I can see my message publish to the distributed topic successfully, but the listener process is not work. Could anyone give me a little clue.
// this one publish msg to the distributed topic.
import javax.naming.*;
import javax.jms.*;
import javax.rmi.PortableRemoteObject ;
import java.util.*;
public class PublishTopic {
public final static String JNDI_FACTORY = "weblogic.jndi.WLInitialContextFactory" ;
public final static String JMS_FACTORY = "weblogic.jws.jms.QueueConnectionFactory" ;
public final static String URL = "t3://localhost:7003,localhost:7005" ;
public final static String DIST_TOPIC = "dist_topic" ;
public String publishMsg(String s) throws Exception {
InitialContext ic = getInitialContext();
TopicConnectionFactory tcf = (TopicConnectionFactory) PortableRemoteObject.narrow
(ic.lookup(JMS_FACTORY),TopicConnectionFactory.class);
TopicConnection tc = tcf.createTopicConnection();
TopicSession ts = tc.createTopicSession(false,Session.AUTO_ACKNOWLEDGE);
Topic t = ts.createTopic(DIST_TOPIC);
TopicPublisher tpub = ts.createPublisher(t);
TextMessage msg = ts.createTextMessage(s);
tc.start();
tpub.publish(msg);
tc.close();
return "publish - : " + msg.getText();
public static InitialContext getInitialContext()throws NamingException {
Hashtable ht = new Hashtable();
ht.put(Context.INITIAL_CONTEXT_FACTORY, JNDI_FACTORY);
ht.put(Context.PROVIDER_URL,URL);
return new InitialContext(ht);
=================================================
// the listener one.
import javax.rmi.PortableRemoteObject ;
import java.util.HashMap;
import java.util.Date;
import javax.naming.*;
import javax.jms.*;
import java.io.*;
public class ListenMsg implements MessageListener {
private static HashMap hm ;
private static TopicConnection tcon ;
static {
// the coding inside static will process once every time
// class load. The code inside here should be
// 1. subscrib to the distributed topic
// 2. refresh the static var.
ListenMsg lm = new ListenMsg();
lm.retrieveDB();
lm.subscribTopic();
lm = null ;
public void onMessage(Message m) {
try {
PrintWriter p = new PrintWriter(new FileOutputStream
("C:/bea/user_projects/applications/TestJMS/JMSLog.txt",true));
p.println(new Date().toLocaleString());
p.println(((TextMessage)m).getText() + "\n");
// check to see the content of m then decide whether
// to call retrieveDB.
} catch (Exception e) {
} finally {
if (tcon != null)
try {
tcon.close();
} catch (Exception e) {}
private void retrieveDB () {
// connect to DB then select the allow/unallow-list.
private void subscribTopic(){
try {
InitialContext ic = PublishTopic.getInitialContext();
TopicConnectionFactory tcf = (TopicConnectionFactory) PortableRemoteObject.narrow
(ic.lookup(PublishTopic.JMS_FACTORY),TopicConnectionFactory.class);
tcon = tcf.createTopicConnection();
TopicSession tsess = tcon.createTopicSession(false,Session.AUTO_ACKNOWLEDGE);
// crateTopic doesn't actually create a new one but instead
// obtain a reference to the object which given name.
Topic t = tsess.createTopic(PublishTopic.DIST_TOPIC);
TopicSubscriber tsub = tsess.createSubscriber(t);
tsub.setMessageListener(this);
tcon.start();
} catch(JMSException je) {
je.printStackTrace();
} catch (NamingException ne) {
ne.printStackTrace();
} catch (Exception e) {
e.printStackTrace();
public boolean isAuthorized(String username, String servicename) {
// check against hm.
return true ;
===============================================
// the web service file.
public class TestPublish implements com.bea.jws.WebService
static final long serialVersionUID = 1L;
* @common:operation
public String sendMsg(String s) throws Exception {
String r = "";
try {
PublishTopic pt = new PublishTopic();
r = pt.publishMsg(s);
} catch(Exception e) {
e.printStackTrace();
throw e;
return r;
A big thanks in advance.
Tanin

Hi
Please verify that the listener points to the correct JNDI name
Do you see any error in the log ?
Jin

Similar Messages

  • Memory leak in a client using EJBs deployed in a Bea Weblogic 10.0.0 cluste

    Hi all,
    We are having a memory leak in a client using stateless EJBs deployed in cluster. The client is a Tomcat 6.0.18 with java 6 but it is reproduced using Tomcat 5 with java 5. The client is calling a Weblogic Server 10.0 making
    calls to an EJB deployed in cluster that has two instances installed in two different machines.
    The client works fine if we shutdown one of the server instances and so when the client is using only one instance.
    Resuming the environment:
    Client Side:
    1 HP-Itanium machine with HP-UX.
    1 Tomcat 6 with java 6 (reproduced with java 5)
    Bea Weblogic client (wlclient.jar) for Weblogic 10.0.0
    Server Side:
    2 HP-Itanium machines with HP-UX
    Bea Weblogic Server 10.0.0 installed in both machines
    An unique domain
    Two Bea instances (one per machines) associated to a Bea Cluster
    EJBs deployed in both instances
    We have monitored the memory consumed in Tomcat and we have noticed that the VM memory PS OLD GEN grows up permanently when we make tests having the two server side Bea Instances up. We have extended
    the memory VM parameters in Tomcat client till 1G and it's only a way to delay the end: the free memory is empty, the GC is not able to free no more byte and the CPU is 100% consumed by the GC work. At the end Tomcat Client
    doesn't accept more http petitions and must be restarted.
    Besides, we have studied the VM memory in Tomcat using jmap and importing it using Eclipse Memory Analyzer. We have seen some strange memory blocks of several Mbytes that are always growing up and that are stored
    under data structures in the package com.sun.corba:
    com.sun.corba.se.impl.legacy.connection.SocketFactoryConnectionImpl (4.5Mb)
    |
    -> com.sun.corba.se.impl.transport.CorbaResponseWaitingRoomImpl
    |
    -> java.util.Hashtable
    |
    -> java.util.Hashtable$Entry
    |
    -> java.util.Hashtable$Entry
    -> java.util.Hashtable$Entry
    -> java.util.Hashtable$Entry
    Has anybody any idea about this problem?
    Thanks in advance.

    Hi all,
    We are having a memory leak in a client using stateless EJBs deployed in cluster. The client is a Tomcat 6.0.18 with java 6 but it is reproduced using Tomcat 5 with java 5. The client is calling a Weblogic Server 10.0 making
    calls to an EJB deployed in cluster that has two instances installed in two different machines.
    The client works fine if we shutdown one of the server instances and so when the client is using only one instance.
    Resuming the environment:
    Client Side:
    1 HP-Itanium machine with HP-UX.
    1 Tomcat 6 with java 6 (reproduced with java 5)
    Bea Weblogic client (wlclient.jar) for Weblogic 10.0.0
    Server Side:
    2 HP-Itanium machines with HP-UX
    Bea Weblogic Server 10.0.0 installed in both machines
    An unique domain
    Two Bea instances (one per machines) associated to a Bea Cluster
    EJBs deployed in both instances
    We have monitored the memory consumed in Tomcat and we have noticed that the VM memory PS OLD GEN grows up permanently when we make tests having the two server side Bea Instances up. We have extended
    the memory VM parameters in Tomcat client till 1G and it's only a way to delay the end: the free memory is empty, the GC is not able to free no more byte and the CPU is 100% consumed by the GC work. At the end Tomcat Client
    doesn't accept more http petitions and must be restarted.
    Besides, we have studied the VM memory in Tomcat using jmap and importing it using Eclipse Memory Analyzer. We have seen some strange memory blocks of several Mbytes that are always growing up and that are stored
    under data structures in the package com.sun.corba:
    com.sun.corba.se.impl.legacy.connection.SocketFactoryConnectionImpl (4.5Mb)
    |
    -> com.sun.corba.se.impl.transport.CorbaResponseWaitingRoomImpl
    |
    -> java.util.Hashtable
    |
    -> java.util.Hashtable$Entry
    |
    -> java.util.Hashtable$Entry
    -> java.util.Hashtable$Entry
    -> java.util.Hashtable$Entry
    Has anybody any idea about this problem?
    Thanks in advance.

  • IS XI Support BEA Weblogic JMS Queue

    Hi
    I have a scenario where i have to send and recive message from the Weblogic JMS Queue ..
    Is XI support Weblogic JMS Queue ..if it is which tranport protocol i have to use to connect to Weblogic queue
    SV

    Hi
    Thanks Ravi..
    U mean to say i have to use the Transport Protocol
    Access JMS Provider with JNDI
    I have few more questions like ..
    what needs to filled in Connection parameters:
    JNDI Look up name of Queue Connection Factory:
    JNDI Look up name of JMS Queue:
    Name of JNDI Initial Context Factory:
    JNDI Sever Address:
    JNDI Logon User:
    JNDI Logon Password:
    When i selected the Protocol some default Values came in do i have have to change any thing
    JNDI Look up name:
    JNDI Look up name of JMS Queue:
    Name of JNDI Initial Context:
    as u mentioned in Server address i will put : t3://server:XXX
    and i have given the user id and Password ..
    the user id and password is same for both JNDI logon and JMS Queue User..
    SV

  • JMSML - XML Based Mark-Up Language for BEA WebLogic JMS and JMX

              JMSML is a Mark-Up language designed and developed to make Java Messaging Service
              (JMS) and Java Management Extensions (JMX) programming easy by hiding all the
              JMS and JMX Java API complexity behind a few, simple, easy to use XML tags.
              Both the White Paper and the binary download are available in dev2dev.beasys.com
              at the link below:
              http://dev2dev.beasys.com/resourcelibrary/whitepapers.jsp?highlight=whitepapers
              Regards
              [email protected]
              

    Hi,
    I finally managed to post a message to ActiveMQ 5.4.2 from WLS 10.3. I created a foreign JMS Server in WLS. I am not sure if you still have this issue, but I was facing this problem and managed to resolve it so posting the reply!
    I placed the activemq-all-5.4.2.jar file in WLS server classpath.
    The settings I used for the Foreign Server are:
    General tab
    JNDI Initial Context Factory: org.apache.activemq.jndi.ActiveMQInitialContextFactory
    JNDI Connection URL: tcp://localhost:61616
    Destinations Tab
    Name: TestQueue
    Local JNDI Name: TestQueue
    Remote JNDI Name: dynamicQueues/TestQueue (I tried with a normal queue, but it didn't work. So used dynamicQueues here. Will try with other queue also)
    Connection Factories Tab
    Name: AMQConnectionFactory (
    Local JNDI Name: AMQConnectionFactory
    Remote JNDI Name: ConnectionFactory (This is default name given by Active MQ, you can change by adding names in jndi.properties file and placing it in config folder of ActiveMQ installation. Please check here: http://activemq.apache.org/jndi-support.html)
    Using this configuration I was able to post message to ActiveMQ queue from Oracle Service Bus. One more issue to be taken care is that if the message type is not "Text" then the message body was coming as blank in ActiveMQ. So set the message type as "Text" explicitly.

  • Bea weblogic jms server to sun seebeyond IQ Manager jms server

    Dear All
    I am working on Bea web logic webserver.
    Now I want deploy message driven bean in it to listen remote queue, which resides in Sun see beyond IQ manager. So is it possible? If yes give me suggestion.
    And both jms servers context was different.
    Thanks
    Vijay

    I am seeing this same error. Was there any resolution to this? We are running WLS 8.1 SP3 on Solaris.
    Thanks

  • Trouble defining BAM Enterprise Message Source for BEA WebLogic Server

    Hi all,
    I've just started to play a little with Oracle BAM Architect.
    I've WLS 10.0 and Oracle BAM Architect 10g release 3.
    On Oracle BAM Architect I've defined an Enterprise Message Source for BEA WebLogic Server as follows:
    Name: ALSBSource
    Owner: ...
    Type: BEA WebLogic Server
    Initial context factory: weblogic.jndi.WLInitialContextFactory
    JNDI Service Provider URL: t3://mypc:7001
    TopicConnectionFactory name: com.myConnectionFactory
    Topic name: com.myBAMTopic
    JMS message type: TextMessage
    Durable subscriber name: BAMSubscriber
    Client ID: BAMSubscriber
    Name | Flow name | Type | Max size | Formatting
    content | BAM | String | 1024 | (none)
    On WLS 10.0 I've defined the required JMS stuff.
    On Oracle Design Studio I've defined a plan that includes:
    - an Oracle BAM Enterprise Message Receiver from which I've selected the above 'ALSBSource' Enterprise Message Source
    - a simple Grid
    I've connected the BAM Enterprise Message Receiver to the Grid and clicked on 'Update' button.
    When I try to publish a message on 'com.myBAMTopic' I don't see anything on the grid defined in the Oracle Design Studio.
    The first question is about the definition of an Enterprise Message Source for BEA WebLogic Server in the Oracle BAM Architect.
    I did not change the Oracle BAM Architect classpath or Oracle Design Studio classpath adding the weblogic.jar, because no error has been raised during the configuration of the message source and the plan. Should I update Oracle classpath with the weblogic.jar ?
    Did I forget any other step ?
    I thank you in advance for any feedback.
    Regards
    ferp

    ferp - I got this to work with
    JNDI Service Provider URL: http://localhost
    When I add the port
    JNDI Service Provider URL: http://localhost:23891
    I cannot get my EMS to start.
    Hopefully this should fix your issue.
    Sudeep.

  • Session Beans  and TIBCO E4JMS and Weblogic JMS 8.1

              Setup:-
              Weblogic Server 8.1 SP2 on Linux
              TIBCO E4JMS 3.1.2
              I have a two Staeless Session Beans which are deployed in both sides of the cluster
              - Cluster is made up of two servers(ManagedServer1 and ManagedServer2) on the
              same machine. The beans have container managed transaction and trans-type set
              to required. The JMS Server is on ManagedServer1. The session bean publishes 100
              messages to TIBCO JMS and Weblogic JMS and calls the second bean which again publishes
              100 messages to TIBCO JMS and Weblogic JMS .
              The connection factories used are XAQueueConnectionFactories.
              This seems to work under the following conditions:-
              a) The session beans are deployed just in ManagedServer1
              b) The WL load balancing scheme manages to run both the beans on ManagedServer1
              c) If I don't publish onto Weblogic JMS( It runs successfully on ManagedServer1
              and ManagedServer2)
              It does not seems to work :-
              When the The WL load balancing scheme manages to run both the beans on ManagedServer2.I
              put debug statements on the beans and it seems to publish everything but fails
              during the commit
              murali@dbuslinux1:~/SessionBeanExample> ant run
              Buildfile: build.xml
              run:
              [java] Run : 0
              [java] InitialContextFactory weblogic.jndi.WLInitialContextFactory
              [java] Provider Url t3://myhost.mycompany.com:18003,myhost.mycompany.com:18005
              [java] javax.transaction.TransactionRolledbackException: Exception while
              commiting Tx : Name=[EJB Case463495.StatelessBean.sendMessageWrap(java.lang.Integer,java.lang.Integer,java.lang.String,boolean,boolean)],Xid=BEA1-000649EC8876A0032A5E(160401684),Status=Rolled
              back. [Reason=javax.transaction.xa.XAException],numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds
              since begin=3,seconds left=30,XAServerResourceInfo[E4JMSDOMAIN.ManagedServer2.JMSXASessionPool.BEAN1TCF]=(ServerResourceInfo[E4JMSDOMAIN.ManagedServer2.JMSXASessionPool.BEAN1TCF]=(state=rolledback,assigned=ManagedServer2),xar=weblogic.deployment.jms.WrappedXAResource_com_tibco_tibjms_TibjmsXAResource@a0181b0),XAServerResourceInfo[JMS_MyJMS
              File Store]=(ServerResourceInfo[JMS_MyJMS File Store]=(state=rolledback,assigned=ManagedServer1),xar=null),XAServerResourceInfo[E4JMSDOMAIN.ManagedServer2.JMSXASessionPool.BEAN2TCF]=(ServerResourceInfo[E4JMSDOMAIN.ManagedServer2.JMSXASessionPool.BEAN2TCF]=(state=rolledback,assigned=ManagedServer2),xar=weblogic.deployment.jms.WrappedXAResource_com_tibco_tibjms_TibjmsXAResource@98f6821),SCInfo[E4JMSDOMAIN+ManagedServer1]=(state=rolledback),SCInfo[E4JMSDOMAIN+ManagedServer2]=(state=rolledback),properties=({weblogic.transaction.name=[EJB
              Case463495.StatelessBean.sendMessageWrap(java.lang.Integer,java.lang.Integer,java.lang.String,boolean,boolean)]}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=ManagedServer2+myhost.mycompany.com:18005+E4JMSDOMAIN+t3+,
              XAResources={},NonXAResources={})],CoordinatorURL=ManagedServer2+myhost.mycompany.com:18005+E4JMSDOMAIN+t3+):
              javax.transaction.xa.XAException
              [java] at com.tibco.tibjms.TibjmsXAResource.end(Ljavax.transaction.xa.Xid;I)V(TibjmsXAResource.java:157)
              [java] at weblogic.deployment.jms.WrappedXAResource_com_tibco_tibjms_TibjmsXAResource.end(Ljavax.transaction.xa.Xid;I)V(Unknown
              Source)
              [java] at weblogic.transaction.internal.XAServerResourceInfo.end(Lweblogic.transaction.internal.ServerTransactionImpl;Ljavax.transaction.xa.Xid;I)V(XAServerResourceInfo.java:1124)
              [java] at weblogic.transaction.internal.XAServerResourceInfo.internalDelist(Lweblogic.transaction.internal.ServerTransactionImpl;I)V(XAServerResourceInfo.java:325)
              [java] at weblogic.transaction.internal.XAServerResourceInfo.delist(Lweblogic.transaction.internal.ServerTransactionImpl;IZ)V(XAServerResourceInfo.java:255)
              [java] at weblogic.transaction.internal.ServerTransactionImpl.delistAll(IZ)V(ServerTransactionImpl.java:1408)
              [java] at weblogic.transaction.internal.ServerTransactionImpl.delistAll(I)V(ServerTransactionImpl.java:1396)
              [java] at weblogic.transaction.internal.ServerTransactionImpl.globalPrepare()V(ServerTransactionImpl.java:1932)
              [java] at weblogic.transaction.internal.ServerTransactionImpl.internalCommit()V(ServerTransactionImpl.java:252)
              [java] at weblogic.transaction.internal.ServerTransactionImpl.commit()V(ServerTransactionImpl.java:221)
              [java] at weblogic.ejb20.internal.BaseEJBObject.postInvoke(Lweblogic.ejb20.interfaces.InvocationWrapper;Ljava.lang.Throwable;)V(BaseEJBObject.java:289)
              [java] at weblogic.ejb20.internal.StatelessEJBObject.postInvoke(Lweblogic.ejb20.interfaces.InvocationWrapper;Ljava.lang.Throwable;)V(StatelessEJBObject.java:141)
              [java] at Case463495.Stateless_soycq8_EOImpl.sendMessageWrap(Ljava.lang.Integer;Ljava.lang.Integer;Ljava.lang.String;ZZ)V(Stateless_soycq8_EOImpl.java:112)
              [java] at Case463495.Stateless_soycq8_EOImpl_WLSkel.invoke(ILweblogic.rmi.spi.InboundRequest;Lweblogic.rmi.spi.OutboundResponse;Ljava.lang.Object;)Lweblogic.rmi.spi.OutboundResponse;(Unknown
              Source)
              [java] at weblogic.rmi.internal.BasicServerRef.invoke(Lweblogic.rmi.extensions.server.RuntimeMethodDescriptor;Lweblogic.rmi.spi.InboundRequest;Lweblogic.rmi.spi.OutboundResponse;)V(BasicServerRef.java:477)
              [java] at weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(Lweblogic.rmi.extensions.server.RuntimeMethodDescriptor;Lweblogic.rmi.spi.InboundRequest;Lweblogic.rmi.spi.OutboundResponse;)V(ReplicaAwareServerRef.java:108)
              [java] at weblogic.rmi.internal.BasicServerRef$1.run()Ljava.lang.Object;(BasicServerRef.java:420)
              [java] at weblogic.security.acl.internal.AuthenticatedSubject.doAs(Lweblogic.security.subject.AbstractSubject;Ljava.security.PrivilegedExceptionAction;)Ljava.lang.Object;(AuthenticatedSubject.java:353)
              [java] at weblogic.security.service.SecurityManager.runAs(Lweblogic.security.acl.internal.AuthenticatedSubject;Lweblogic.security.acl.internal.AuthenticatedSubject;Ljava.security.PrivilegedExceptionAction;)Ljava.lang.Object;(SecurityManager.java:144)
              [java] at weblogic.rmi.internal.BasicServerRef.handleRequest(Lweblogic.rmi.spi.InboundRequest;)V(BasicServerRef.java:415)
              [java] at weblogic.rmi.internal.BasicExecuteRequest.execute(Lweblogic.kernel.ExecuteThread;)V(BasicExecuteRequest.java:30)
              [java] at weblogic.kernel.ExecuteThread.execute(Lweblogic.kernel.ExecuteRequest;)V(ExecuteThread.java:197)
              [java] at weblogic.kernel.ExecuteThread.run()V(ExecuteThread.java:170)
              [java] at java.lang.Thread.startThreadFromVM(Ljava.lang.Thread;)V(Unknown
              Source)
              [java] ; nested exception is:
              [java] javax.transaction.xa.XAException
              [java] at weblogic.rjvm.BasicOutboundRequest.sendReceive()Lweblogic.rmi.spi.InboundResponse;(BasicOutboundRequest.java:108)
              [java] at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(Lweblogic.rmi.extensions.server.RemoteReference;Lweblogic.rmi.extensions.server.RuntimeMethodDescriptor;[Ljava.lang.Object;Ljava.lang.reflect.Method;)Ljava.lang.Object;(ReplicaAwareRemoteRef.java:284)
              [java] at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(Ljava.rmi.Remote;Lweblogic.rmi.extensions.server.RuntimeMethodDescriptor;[Ljava.lang.Object;Ljava.lang.reflect.Method;)Ljava.lang.Object;(ReplicaAwareRemoteRef.java:244)
              [java] at Case463495.Stateless_soycq8_EOImpl_812_WLStub.sendMessageWrap(Ljava.lang.Integer;Ljava.lang.Integer;Ljava.lang.String;ZZ)V(Unknown
              Source)
              [java] at Case463495.Client.run()V(Client.java:103)
              [java] at Case463495.Client.sendMessage()V(Client.java:132)
              [java] at Case463495.Client.main([Ljava.lang.String;)V(Client.java:195)
              [java] Caused by: javax.transaction.xa.XAException
              [java] at com.tibco.tibjms.TibjmsXAResource.end(TibjmsXAResource.java:157)
              [java] at weblogic.deployment.jms.WrappedXAResource_com_tibco_tibjms_TibjmsXAResource.end(Unknown
              Source)
              [java] at weblogic.transaction.internal.XAServerResourceInfo.end(XAServerResourceInfo.java:1124)
              [java] at weblogic.transaction.internal.XAServerResourceInfo.internalDelist(XAServerResourceInfo.java:325)
              [java] at weblogic.transaction.internal.XAServerResourceInfo.delist(XAServerResourceInfo.java:255)
              [java] at weblogic.transaction.internal.ServerTransactionImpl.delistAll(ServerTransactionImpl.java:1408)
              [java] at weblogic.transaction.internal.ServerTransactionImpl.delistAll(ServerTransactionImpl.java:1396)
              [java] at weblogic.transaction.internal.ServerTransactionImpl.globalPrepare(ServerTransactionImpl.java:1932)
              [java] at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:252)
              [java] at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:221)
              [java] at weblogic.ejb20.internal.BaseEJBObject.postInvoke(BaseEJBObject.java:289)
              [java] at weblogic.ejb20.internal.StatelessEJBObject.postInvoke(StatelessEJBObject.java:141)
              [java] at Case463495.Stateless_soycq8_EOImpl.sendMessageWrap(Stateless_soycq8_EOImpl.java:112)
              [java] at Case463495.Stateless_soycq8_EOImpl_WLSkel.invoke(Unknown Source)
              [java] at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:477)
              [java] at weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServerRef.java:108)
              [java] at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:420)
              [java] at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:353)
              [java] at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:144)
              [java] at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:415)
              [java] at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:30)
              [java] at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
              [java] at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
              [java] at java.lang.Thread.startThreadFromVM(Unknown Source)
              Apologies in advance if this need to be posted in the JTA news group..
              Any ideas?
              Murali
              

    Posting to the transaction newsgroup would probably also be helpful.
              Can you post the code for the session bean so we can see how you're
              enlisting Tibco in the transaction? It looks like you're using the JMS
              provider wrappers from 8.1, which do the transaction enlistment for you, so
              you shouldn't need to mess with JTA at all in your code. Still, something
              weird is going on and it'd be nice to see exactly what your code looks like.
              greg
              "L Muralidharan" <[email protected]> wrote in message
              news:[email protected]...
              >
              > Setup:-
              >
              > Weblogic Server 8.1 SP2 on Linux
              >
              > TIBCO E4JMS 3.1.2
              >
              > I have a two Staeless Session Beans which are deployed in both sides of
              the cluster
              > - Cluster is made up of two servers(ManagedServer1 and ManagedServer2) on
              the
              > same machine. The beans have container managed transaction and trans-type
              set
              > to required. The JMS Server is on ManagedServer1. The session bean
              publishes 100
              > messages to TIBCO JMS and Weblogic JMS and calls the second bean which
              again publishes
              > 100 messages to TIBCO JMS and Weblogic JMS .
              >
              > The connection factories used are XAQueueConnectionFactories.
              >
              > This seems to work under the following conditions:-
              >
              > a) The session beans are deployed just in ManagedServer1
              > b) The WL load balancing scheme manages to run both the beans on
              ManagedServer1
              > c) If I don't publish onto Weblogic JMS( It runs successfully on
              ManagedServer1
              > and ManagedServer2)
              >
              > It does not seems to work :-
              >
              > When the The WL load balancing scheme manages to run both the beans on
              ManagedServer2.I
              > put debug statements on the beans and it seems to publish everything but
              fails
              > during the commit
              >
              > murali@dbuslinux1:~/SessionBeanExample> ant run
              > Buildfile: build.xml
              >
              > run:
              > [java] Run : 0
              > [java] InitialContextFactory weblogic.jndi.WLInitialContextFactory
              > [java] Provider Url
              t3://myhost.mycompany.com:18003,myhost.mycompany.com:18005
              > [java] javax.transaction.TransactionRolledbackException: Exception
              while
              > commiting Tx : Name=[EJB
              Case463495.StatelessBean.sendMessageWrap(java.lang.Integer,java.lang.Integer
              ,java.lang.String,boolean,boolean)],Xid=BEA1-000649EC8876A0032A5E(160401684)
              ,Status=Rolled
              > back.
              [Reason=javax.transaction.xa.XAException],numRepliesOwedMe=0,numRepliesOwedO
              thers=0,seconds
              > since begin=3,seconds
              left=30,XAServerResourceInfo[E4JMSDOMAIN.ManagedServer2.JMSXASessionPool.BEA
              N1TCF]=(ServerResourceInfo[E4JMSDOMAIN.ManagedServer2.JMSXASessionPool.BEAN1
              TCF]=(state=rolledback,assigned=ManagedServer2),xar=weblogic.deployment.jms.
              WrappedXAResource_com_tibco_tibjms_TibjmsXAResource@a0181b0),XAServerResourc
              eInfo[JMS_MyJMS
              > File Store]=(ServerResourceInfo[JMS_MyJMS File
              Store]=(state=rolledback,assigned=ManagedServer1),xar=null),XAServerResource
              Info[E4JMSDOMAIN.ManagedServer2.JMSXASessionPool.BEAN2TCF]=(ServerResourceIn
              fo[E4JMSDOMAIN.ManagedServer2.JMSXASessionPool.BEAN2TCF]=(state=rolledback,a
              ssigned=ManagedServer2),xar=weblogic.deployment.jms.WrappedXAResource_com_ti
              bco_tibjms_TibjmsXAResource@98f6821),SCInfo[E4JMSDOMAIN+ManagedServer1]=(sta
              te=rolledback),SCInfo[E4JMSDOMAIN+ManagedServer2]=(state=rolledback),propert
              ies=({weblogic.transaction.name=[EJB
              >
              Case463495.StatelessBean.sendMessageWrap(java.lang.Integer,java.lang.Integer
              ,java.lang.String,boolean,boolean)]}),OwnerTransactionManager=ServerTM[Serve
              rCoordinatorDescriptor=(CoordinatorURL=ManagedServer2+myhost.mycompany.com:1
              8005+E4JMSDOMAIN+t3+,
              >
              XAResources={},NonXAResources={})],CoordinatorURL=ManagedServer2+myhost.myco
              mpany.com:18005+E4JMSDOMAIN+t3+):
              > javax.transaction.xa.XAException
              > [java] at
              com.tibco.tibjms.TibjmsXAResource.end(Ljavax.transaction.xa.Xid;I)V(TibjmsXA
              Resource.java:157)
              > [java] at
              weblogic.deployment.jms.WrappedXAResource_com_tibco_tibjms_TibjmsXAResource.
              end(Ljavax.transaction.xa.Xid;I)V(Unknown
              > Source)
              > [java] at
              weblogic.transaction.internal.XAServerResourceInfo.end(Lweblogic.transaction
              .internal.ServerTransactionImpl;Ljavax.transaction.xa.Xid;I)V(XAServerResour
              ceInfo.java:1124)
              > [java] at
              weblogic.transaction.internal.XAServerResourceInfo.internalDelist(Lweblogic.
              transaction.internal.ServerTransactionImpl;I)V(XAServerResourceInfo.java:325
              > [java] at
              weblogic.transaction.internal.XAServerResourceInfo.delist(Lweblogic.transact
              ion.internal.ServerTransactionImpl;IZ)V(XAServerResourceInfo.java:255)
              > [java] at
              weblogic.transaction.internal.ServerTransactionImpl.delistAll(IZ)V(ServerTra
              nsactionImpl.java:1408)
              > [java] at
              weblogic.transaction.internal.ServerTransactionImpl.delistAll(I)V(ServerTran
              sactionImpl.java:1396)
              > [java] at
              weblogic.transaction.internal.ServerTransactionImpl.globalPrepare()V(ServerT
              ransactionImpl.java:1932)
              > [java] at
              weblogic.transaction.internal.ServerTransactionImpl.internalCommit()V(Server
              TransactionImpl.java:252)
              > [java] at
              weblogic.transaction.internal.ServerTransactionImpl.commit()V(ServerTransact
              ionImpl.java:221)
              > [java] at
              weblogic.ejb20.internal.BaseEJBObject.postInvoke(Lweblogic.ejb20.interfaces.
              InvocationWrapper;Ljava.lang.Throwable;)V(BaseEJBObject.java:289)
              > [java] at
              weblogic.ejb20.internal.StatelessEJBObject.postInvoke(Lweblogic.ejb20.interf
              aces.InvocationWrapper;Ljava.lang.Throwable;)V(StatelessEJBObject.java:141)
              > [java] at
              Case463495.Stateless_soycq8_EOImpl.sendMessageWrap(Ljava.lang.Integer;Ljava.
              lang.Integer;Ljava.lang.String;ZZ)V(Stateless_soycq8_EOImpl.java:112)
              > [java] at
              Case463495.Stateless_soycq8_EOImpl_WLSkel.invoke(ILweblogic.rmi.spi.InboundR
              equest;Lweblogic.rmi.spi.OutboundResponse;Ljava.lang.Object;)Lweblogic.rmi.s
              pi.OutboundResponse;(Unknown
              > Source)
              > [java] at
              weblogic.rmi.internal.BasicServerRef.invoke(Lweblogic.rmi.extensions.server.
              RuntimeMethodDescriptor;Lweblogic.rmi.spi.InboundRequest;Lweblogic.rmi.spi.O
              utboundResponse;)V(BasicServerRef.java:477)
              > [java] at
              weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(Lweblogic.rmi.extensions.s
              erver.RuntimeMethodDescriptor;Lweblogic.rmi.spi.InboundRequest;Lweblogic.rmi
              .spi.OutboundResponse;)V(ReplicaAwareServerRef.java:108)
              > [java] at
              weblogic.rmi.internal.BasicServerRef$1.run()Ljava.lang.Object;(BasicServerRe
              f.java:420)
              > [java] at
              weblogic.security.acl.internal.AuthenticatedSubject.doAs(Lweblogic.security.
              subject.AbstractSubject;Ljava.security.PrivilegedExceptionAction;)Ljava.lang
              .Object;(AuthenticatedSubject.java:353)
              > [java] at
              weblogic.security.service.SecurityManager.runAs(Lweblogic.security.acl.inter
              nal.AuthenticatedSubject;Lweblogic.security.acl.internal.AuthenticatedSubjec
              t;Ljava.security.PrivilegedExceptionAction;)Ljava.lang.Object;(SecurityManag
              er.java:144)
              > [java] at
              weblogic.rmi.internal.BasicServerRef.handleRequest(Lweblogic.rmi.spi.Inbound
              Request;)V(BasicServerRef.java:415)
              > [java] at
              weblogic.rmi.internal.BasicExecuteRequest.execute(Lweblogic.kernel.ExecuteTh
              read;)V(BasicExecuteRequest.java:30)
              > [java] at
              weblogic.kernel.ExecuteThread.execute(Lweblogic.kernel.ExecuteRequest;)V(Exe
              cuteThread.java:197)
              > [java] at
              weblogic.kernel.ExecuteThread.run()V(ExecuteThread.java:170)
              > [java] at
              java.lang.Thread.startThreadFromVM(Ljava.lang.Thread;)V(Unknown
              > Source)
              > [java] ; nested exception is:
              > [java] javax.transaction.xa.XAException
              > [java] at
              weblogic.rjvm.BasicOutboundRequest.sendReceive()Lweblogic.rmi.spi.InboundRes
              ponse;(BasicOutboundRequest.java:108)
              > [java] at
              weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(Lweblogic.rmi.extensions.s
              erver.RemoteReference;Lweblogic.rmi.extensions.server.RuntimeMethodDescripto
              r;[Ljava.lang.Object;Ljava.lang.reflect.Method;)Ljava.lang.Object;(ReplicaAw
              areRemoteRef.java:284)
              > [java] at
              weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(Ljava.rmi.Remote;Lweblogic
              .rmi.extensions.server.RuntimeMethodDescriptor;[Ljava.lang.Object;Ljava.lang
              .reflect.Method;)Ljava.lang.Object;(ReplicaAwareRemoteRef.java:244)
              > [java] at
              Case463495.Stateless_soycq8_EOImpl_812_WLStub.sendMessageWrap(Ljava.lang.Int
              eger;Ljava.lang.Integer;Ljava.lang.String;ZZ)V(Unknown
              > Source)
              > [java] at Case463495.Client.run()V(Client.java:103)
              > [java] at Case463495.Client.sendMessage()V(Client.java:132)
              > [java] at
              Case463495.Client.main([Ljava.lang.String;)V(Client.java:195)
              > [java] Caused by: javax.transaction.xa.XAException
              > [java] at
              com.tibco.tibjms.TibjmsXAResource.end(TibjmsXAResource.java:157)
              > [java] at
              weblogic.deployment.jms.WrappedXAResource_com_tibco_tibjms_TibjmsXAResource.
              end(Unknown
              > Source)
              > [java] at
              weblogic.transaction.internal.XAServerResourceInfo.end(XAServerResourceInfo.
              java:1124)
              > [java] at
              weblogic.transaction.internal.XAServerResourceInfo.internalDelist(XAServerRe
              sourceInfo.java:325)
              > [java] at
              weblogic.transaction.internal.XAServerResourceInfo.delist(XAServerResourceIn
              fo.java:255)
              > [java] at
              weblogic.transaction.internal.ServerTransactionImpl.delistAll(ServerTransact
              ionImpl.java:1408)
              > [java] at
              weblogic.transaction.internal.ServerTransactionImpl.delistAll(ServerTransact
              ionImpl.java:1396)
              > [java] at
              weblogic.transaction.internal.ServerTransactionImpl.globalPrepare(ServerTran
              sactionImpl.java:1932)
              > [java] at
              weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTra
              nsactionImpl.java:252)
              > [java] at
              weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransaction
              Impl.java:221)
              > [java] at
              weblogic.ejb20.internal.BaseEJBObject.postInvoke(BaseEJBObject.java:289)
              > [java] at
              weblogic.ejb20.internal.StatelessEJBObject.postInvoke(StatelessEJBObject.jav
              a:141)
              > [java] at
              Case463495.Stateless_soycq8_EOImpl.sendMessageWrap(Stateless_soycq8_EOImpl.j
              ava:112)
              > [java] at
              Case463495.Stateless_soycq8_EOImpl_WLSkel.invoke(Unknown Source)
              > [java] at
              weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:477)
              > [java] at
              weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServerRef.java
              :108)
              > [java] at
              weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:420)
              > [java] at
              weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubjec
              t.java:353)
              > [java] at
              weblogic.security.service.SecurityManager.runAs(SecurityManager.java:144)
              > [java] at
              weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:415)
              > [java] at
              weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:3
              0)
              > [java] at
              weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
              > [java] at
              weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
              > [java] at java.lang.Thread.startThreadFromVM(Unknown Source)
              >
              >
              > Apologies in advance if this need to be posted in the JTA news group..
              >
              > Any ideas?
              >
              > Murali
              >
              

  • Weblogic 10.3 not suporting for MDB to connect remote Weblogic JMS server

    Hi,
    I have a problem with MDB deployed on Weblogic 10.3.It's simple MDB which is communicating with remote weblogic JMS server. I am getting below exception. could some one help how to resolve this issue.
    <Apr 14, 2009 11:28:52 AM PDT> <Warning> <EJB> <BEA-010061> <The Message-Driven EJB: ReceiverFromDocumentum is unable to con
    nect to the JMS destination: FMAContractOutboundQueue. The Error was:
    [EJB:011013]The Message-Driven EJB attempted to connect to the JMS connection factory with the JNDI name: FMAConnectionFacto
    ry. However, the object with the JNDI name: FMAConnectionFactory is not a JMS connection factory. NestedException Message is
    :weblogic.jms.client.JMSConnectionFactory cannot be cast to javax.jms.XAConnectionFactory>
    -Sreekanth

    I recall that this particular warning message is sometimes misleading about the root cause of the problem, an issue that I think has been fixed in a patch. The actual problem can be various:
    * The MDB is configured to be transactional, the connection factory exists, but the connection factory isn't configured to be "XA enabled". (I think this is the most likely problem).
    * The connection factory doesn't exist.
    * The object in JNDI with the specified connection factory name isn't actually a connection factory.
    * The dest object in JNDI with the specified name isn't actually a javax.jms.Destination
    Note that its unusual to configure the connection factory name for an MDB that consumes from WebLogic JMS. The default name iis usually sufficient unless custom tuning is required on the connection factory. See the MDB section of the EJB developer guide for more information.
    Tom

  • Error when trying to enqueue message on to weblogic JMS queue

    Hi,
    I have developed a BPEL process to enqueue message on to a JMS queue in weblogic 10.3.1.BPEL process manager version is 10.1.3.4. I have referred the Oracle note 549016.1 for configuring the Jms adapter for BEA Weblogic JMS Provider.
    In the invoke activity, I am getting the following error:
    "Missing class: weblogic.security.acl.UserInfo
    Dependent class: weblogic.jndi.WLInitialContextFactory
    Loader: JmsAdapter:0.0.0
    Code-Source: /D:/product/10.1.3.1/orasoa/j2ee/oc4j_soa/connectors/JmsAdapter/JmsAdapter/weblogic.jar
    Configuration: &lt;code-source> in D:\product\10.1.3.1\orasoa\j2ee\oc4j_soa\connectors\JmsAdapter\JmsAdapter
    The missing class is not available from any code-source or loader in the system."
    I could not find a resolution. Please provide your inputs.
    Thanks.
    John

    Could be this, if the above fix was by generating a wlfull client jar:
    http://download.oracle.com/docs/cd/E14571_01/web.1111/e13717/jarbuilder.htm#BABCGHFH
    Edited by: atheek1 on Jul 28, 2010 9:39 PM

  • Welcome to the BEA WebLogic Server Version 6.0 Beta Program!

    Welcome to the BEA WebLogic Server Version 6.0 Beta Program!
    We are very excited about this beta program and appreciate your
    participation. In the past, our public betas have been very well received
    by our developer community. So, we have once again organized a public beta
    program to enable everyone to preview our latest release.
    We do ask that you follow a few guidelines:
    -- There will be no voice, e-mail, or fax support for this beta through the
    technical support organization. All questions, bug reports, or comments on
    the beta program should be directed to to the WebLogic beta newsgroups at
    news://newsgroups.bea.com. These newsgroups are:
    weblogic.developer.interest.60beta.transaction
    weblogic.support.install.60beta
    weblogic.developer.interest.60beta.ejb
    weblogic.developer.interest.60beta.clustering
    weblogic.developer.interest.60beta.security
    weblogic.developer.interest.60beta.jdbc
    weblogic.developer.interest.60beta.jms
    weblogic.developer.interest.60beta.performance
    weblogic.developer.interest.60beta.misc
    weblogic.developer.interest.60beta.servlet
    weblogic.developer.interest.60beta.jsp
    weblogic.developer.interest.60beta.tools
    weblogic.developer.interest.60beta.rmi-iiop
    weblogic.developer.interest.60beta.management
    weblogic.developer.interest.60beta.management.console
    weblogic.developer.interest.60beta.management.general_and_jmx
    weblogic.developer.interest.60beta.internationalization
    weblogic.developer.interest.60beta.xml
    weblogic.developer.interest.60beta.jndi
    weblogic.developer.interest.60beta.documentation
    weblogic.developer.interest.60beta.javamail
    -- Please remember that this release is currently beta code. This means that
    it should not be put into production deployments until the final release
    occurs.
    -- It is very likely that this release will contain bugs and errors. This is
    the nature of beta code. Please the patient with us as we do our best to fix
    any problems that we find. We will do our absolute best to make sure that
    your issues are addressed as soon as possible.
    -- Please do not post any issues relevant to the beta on the standard
    newsgroups also available at news://newsgroups.bea.com.
    -- Please use the newsgroup for all communication and do not contact any BEA
    employees directly. They have been instructed to direct you to comment only
    via the newsgroup.
    -- Please review previous posts in the newsgroups before posting. If you
    locate a bug or need to ask a question, it is very likely that it will have
    been asked before.
    -- Please do not post on the newsgroup using hostile or profane language.
    Inappropriate posts will be removed and offenders will be blocked from the
    beta program.
    Thank you again for your support and participation. We very much appreciate
    all that you will be doing to make this release of the BEA WebLogic Server
    as great as possible.
    Michael Girdley
    BEA Systems Inc

    Welcome to the BEA WebLogic Server Version 6.0 Beta Program!
    We are very excited about this beta program and appreciate your
    participation. In the past, our public betas have been very well received
    by our developer community. So, we have once again organized a public beta
    program to enable everyone to preview our latest release.
    We do ask that you follow a few guidelines:
    -- There will be no voice, e-mail, or fax support for this beta through the
    technical support organization. All questions, bug reports, or comments on
    the beta program should be directed to to the WebLogic beta newsgroups at
    news://newsgroups.bea.com. These newsgroups are:
    weblogic.developer.interest.60beta.transaction
    weblogic.support.install.60beta
    weblogic.developer.interest.60beta.ejb
    weblogic.developer.interest.60beta.clustering
    weblogic.developer.interest.60beta.security
    weblogic.developer.interest.60beta.jdbc
    weblogic.developer.interest.60beta.jms
    weblogic.developer.interest.60beta.performance
    weblogic.developer.interest.60beta.misc
    weblogic.developer.interest.60beta.servlet
    weblogic.developer.interest.60beta.jsp
    weblogic.developer.interest.60beta.tools
    weblogic.developer.interest.60beta.rmi-iiop
    weblogic.developer.interest.60beta.management
    weblogic.developer.interest.60beta.management.console
    weblogic.developer.interest.60beta.management.general_and_jmx
    weblogic.developer.interest.60beta.internationalization
    weblogic.developer.interest.60beta.xml
    weblogic.developer.interest.60beta.jndi
    weblogic.developer.interest.60beta.documentation
    weblogic.developer.interest.60beta.javamail
    -- Please remember that this release is currently beta code. This means that
    it should not be put into production deployments until the final release
    occurs.
    -- It is very likely that this release will contain bugs and errors. This is
    the nature of beta code. Please the patient with us as we do our best to fix
    any problems that we find. We will do our absolute best to make sure that
    your issues are addressed as soon as possible.
    -- Please do not post any issues relevant to the beta on the standard
    newsgroups also available at news://newsgroups.bea.com.
    -- Please use the newsgroup for all communication and do not contact any BEA
    employees directly. They have been instructed to direct you to comment only
    via the newsgroup.
    -- Please review previous posts in the newsgroups before posting. If you
    locate a bug or need to ask a question, it is very likely that it will have
    been asked before.
    -- Please do not post on the newsgroup using hostile or profane language.
    Inappropriate posts will be removed and offenders will be blocked from the
    beta program.
    Thank you again for your support and participation. We very much appreciate
    all that you will be doing to make this release of the BEA WebLogic Server
    as great as possible.
    Michael Girdley
    BEA Systems Inc

  • Weblogic admin server in the cluster !!!!

    Hi,
    I am working on weblogic setup already done by my ex-colleague. I observed that, the admin server is also participating in the cluster and hence it is also one of the targets for EJB components, datasource and connection pool. Is there any performance issue in this setup ?
    thanks for your time.

    Thank you for your reply.
    I forgot to tell you that the admin server is not an individual machine. It is setup in one of the weblogic App. servers. Therefore, I feel it is better we do not add this admin server in the cluster.
    You can give me your advice. ---- topic 1
    By the way, I had posted one question about targeting a datasource to the individual servers rather than to a cluster. In the existing setup, the datasource is targeted to individual servers rather
    than to the cluster. The setup is running without any error.
    But as per the BEA manual, we have to target the datasource to the cluster if we use cluster. So, in my current setup, is there any performance issue or may I face any problem in future by not targeting the datasource to the cluster? I appreciate if you can
    try this question. ---- topic 2
    Thanks in advance.

  • Weblogic JMS Cluster

    Hi,
              I have a 6.1 cluster that has a JMS server A and a JMS Server B
              deployed and running on each of the managed nodes. As destination I
              created a topic with the same name for each JMS Server. The connection
              factories I deployed to the cluster only.
              My problem is, when I start the second managed server, I get the
              following error:
              <Error> <Cluster> <Conflict start: You tried to bind an object under
              the name
              com.csg.pb.tit.tms.TMSSignalTopic in the JNDI tree. The object you
              have bound
              from 169.59.5.26 is non clusterable and you have tried to bind more
              than once
              from two or more servers. Such objects can only deployed from one
              server.>
              When I understand correctly, this happens because the JNDI tree gets
              distributed to all nodes of the cluster, so there would be two object
              with the same name. How do I solve this situation? Do I have the
              specify different names for topics in different JMSServer running in a
              cluster? How would the load balancing work?
              Please help. Thanks in advance
              Juerg
              

    Tom,
              Thanks for your help so far, I installed the patch and got things
              working. However I still have some open points where you might be able
              to help.
              Let's assume I don't have these smart forwarders and I have four
              topics per JMSServer deployed to two managed nodes. Connection
              factories deployed to the cluster. When I connect N publishers
              through the cluster, messages from one publisher end up in the
              appropriate topic on nodeA, messages from another publisher end up in
              the appropriate topic on nodeB. Now when I connect a durable
              subscriber via the cluster I only get messages from topics from one of
              the managed nodes, right? (This is exactly what I am seeing in my
              tests) Connecting durable subscribers to each managed node is not
              possible because of JNDI (throws exception like
              InstanceAlreadyExists). How would I connect a subscriber so that it
              subscribes to the right topics on the right node ( one the works with
              the previously described publisher)?
              All this leads me to the conclusion, that without the forwarders, a
              JMS cluster with Weblogic 6.1 is not so powerful, it basically does
              just load balacing.
              Is this correct or am I missing something important here?
              Thanks a lot and have a nice weekend
              Juerg
              Tom Barnes <[email protected]> wrote in message news:<[email protected]>...
              > Juerg Staub wrote:
              > > Tom,
              > >
              > > Thanks a lot. Bascially I did everything right, just need the patch.
              > >
              > > In the other hand I'd like to know what the benefits of the smart
              > > forwarders would be. When I understand correctly, every message would
              > > be forwarded to the appropriate topic in the different JMS servers.
              > > What would that bring in the case of a failure(one node of a cluster
              > > goes down)? As far as I can see, I still would need to 're-establish'
              > > the connection factory, topic session, topic and publisher in order to
              > > publish messages again?
              > >
              >
              > Yep. I think we are on the same page:
              >
              > The "smart-forwarders" would do what the 7.0 distributed topic
              > forwarders do for you. They would forward messages bound to
              > a particular physical topic to all instances of the topic.
              > This can be implemented via a durable subscription on a
              > member topic by each remote member topic's host.
              > MDBs could be used to service the durable subscription,
              > as they already have the reconnect logic built in.
              > (Durable subscriptions are used if you wish to guard against
              > lost messages). The forwarders
              > need to change a property on the message to indicate
              > that the message is already forwarded, and forward
              > only messages that have'nt been forwarded (to prevent
              > endless loops!).
              >
              >
              > > Thanks
              > >
              > > Juerg
              > >
              > > Tom Barnes <[email protected]> wrote in message news:<[email protected]>...
              > >
              > >>I suggest you read the "emulating 7.0 distributed destinations"
              > >>section of the JMS performance white-paper available on dev2dev.bea.com.
              > >>You will need to apply the referenced enhancement patch on top of SP3 to
              > >>disable JNDI replication (or update to 6.1SP4).
              > >>
              > >>If you need to create a true distributed topic, you will also need to
              > >>write your own "smart-forwarders" to forward messages
              > >>between the different physical instances of the topic. Or simply
              > >>use WL JMS 7.0 (the upgrade from 6.1 is straight-forward).
              > >>
              > >>Tom
              > >>
              > >>Juerg Staub wrote:
              > >>
              > >>>Hi,
              > >>>
              > >>>I have a 6.1 cluster that has a JMS server A and a JMS Server B
              > >>>deployed and running on each of the managed nodes. As destination I
              > >>>created a topic with the same name for each JMS Server. The connection
              > >>>factories I deployed to the cluster only.
              > >>>
              > >>>My problem is, when I start the second managed server, I get the
              > >>>following error:
              > >>>
              > >>><Error> <Cluster> <Conflict start: You tried to bind an object under
              > >>>the name
              > >>>com.csg.pb.tit.tms.TMSSignalTopic in the JNDI tree. The object you
              > >>>have bound
              > >>>from 169.59.5.26 is non clusterable and you have tried to bind more
              > >>>than once
              > >>>from two or more servers. Such objects can only deployed from one
              > >>>server.>
              > >>>
              > >>>
              > >>>When I understand correctly, this happens because the JNDI tree gets
              > >>>distributed to all nodes of the cluster, so there would be two object
              > >>>with the same name. How do I solve this situation? Do I have the
              > >>>specify different names for topics in different JMSServer running in a
              > >>>cluster? How would the load balancing work?
              > >>>
              > >>>
              > >>>Please help. Thanks in advance
              > >>>
              > >>>Juerg
              > >>
              

  • Always selecting the local JMS in a cluster, is it possible? (in 6.1)

    Hi,
              A 6.1 cluster has a JMS server running on each node. The JMS client
              code has a component to do the fail over "manually": it tries one
              node, if that doesn't work it tries the next and so on. The
              destination names are different (and replicated in the JNDI tree).
              If everything is ok, all requests go the first server (meaning network
              traffic). Is there an elegant way to always try with the local JMS
              server before the remote ones, without minimum configuration
              dependency (i.e. no system properties passed at start-up telling what
              JMS servers to use and so on)
              Perhaps something using JMSDestinationRuntimeMBean and
              JMSServerRuntimeMBean?
              Oh, just noticed JMSRuntimeMBean.html.getJMSServers(), this might do
              it. I'll post it nonetheless in case other people have better ideas.
              Thanks.
              

    Thanks again.
              In fact, if I use the server/queue syntax, I can use the queue name
              (the Name attrribute) not the JNDI name. This in case these names can
              be the same in a cluster deployment (with replicated JNDI names
              different). I'll check soon.
              Regarding the connection factory, I wonder whether WL doesn't do its
              otherwise typical performance improvements and return a local
              connection if there is one (as it already does with remote
              interfaces). I couldn't find a reference to such an optimization in
              the JMS documentation, though.
              On Wed, 17 Apr 2002 09:37:59 -0400, Tom Barnes
              <[email protected]> wrote:
              >email wrote:
              >
              >> Thank you. The second option looks better than the first because it
              >> allows using destinations on other JMS servers (by interrogating an
              >> MBean to get the JMS servers in the cluster).
              >
              >The second option only works if the connection is already connected
              >to the correct server. If you use mbeans, you can glean the URL
              >of the correct server by obtaining the IP and address of the remote
              >server from the ServerMBean - the "target" of the JMSServerMBean.
              >
              >An issue with this feature is the connection factory - which round-robins the
              >location of connection in certain cases. Currently the only way to ensure the
              >connection
              >factory does not do this is to target it at a single server. I suppose one
              >could duplicate the connection factory and target each duplicate at
              >a different server, but that requires giving each one a different name.
              >This may not be an issue with server-side contexts, I will investigate.
              >
              >
              >> It's useful to know
              >> about JNDINameReplicated, but that way accessing a remote destination
              >> will not be possible at all.
              >>
              >
              >I think you could write a small a startup class to look up the queue in the
              >local context and register the queue in a
              >replicated context with a different JNDI name. This way the destination
              >is advertised both ways. Fairly sure this would work.
              >
              >>
              >> BTW, a related question on reliability: accessing a remote destination
              >> if the local is down means there is a local problem with the JMS
              >> server or the queue, but the container is fine. Now, how likely is
              >> this in practice? Having the container up but the JMS subsystem down.
              >>
              >
              >Parts (or all) of JMS can fail due to configuration
              >errors -- commonly JNDI name collisions of destinations and/or factories,
              >failure to set the target, or using the same server name or jms server name
              >on two different servers.
              >
              >If you are using a file-store, boot failures occur with things
              >like file-store not found, or relatively catastrophic failures like
              >out-of-memory.
              >
              >If you are using a JDBC store, there is a dependency on the database being up.
              >
              >
              >>
              >> Indeed, 7.0 would solve it but that's several months ahead if I
              >> understand correctly:)
              >>
              >
              >Not months. Weeks. A very few weeks. I'm not sure what is officially
              >announced
              >so I can't get more specific.
              >
              >>
              >> Thanks again.
              >>
              >> On Tue, 16 Apr 2002 14:48:02 -0400, Tom Barnes
              >> <[email protected]> wrote:
              >>
              >> >Consider the new "JNDINameReplicated" configuration parm on the
              >> >destination. Ensure each server running 6.0SP2 with patch CR061106, or
              >> >6.1SP3 (not out yet) and later, or 7.0. Configure each queue to have the
              >> >same JNDI name, and also take care to set the destination’s new
              >> >“JNDINameReplicated” parameter to false. This turns off name
              >> >replications, so the JNDI name of the dest is only visible on the server
              >> >local to the context.
              >> >
              >> >Consider naming all destinations the same and looking them up the dest via
              >> >session.createQueue("./queuename"), this is a new syntax that restricts
              >> >the lookup to the same server as the one the JMS connection is talking
              >> >to. The normal syntax is "servername/queuename". This feature is
              >> >slated for 6.1SP3, no guarantees, (or try ask customer support to get this
              >> >feature in early as a patch, no guarantees there either), or 7.0.
              >> >
              >> >Consider not rolling your own and using 7.0, which has a rich distributed
              >> >destination feature built in.
              >> >
              >> >Tom
              >> >
              >> >email wrote:
              >> >
              >> >> Hi,
              >> >>
              >> >> A 6.1 cluster has a JMS server running on each node. The JMS client
              >> >> code has a component to do the fail over "manually": it tries one
              >> >> node, if that doesn't work it tries the next and so on. The
              >> >> destination names are different (and replicated in the JNDI tree).
              >> >>
              >> >> If everything is ok, all requests go the first server (meaning network
              >> >> traffic). Is there an elegant way to always try with the local JMS
              >> >> server before the remote ones, without minimum configuration
              >> >> dependency (i.e. no system properties passed at start-up telling what
              >> >> JMS servers to use and so on)
              >> >>
              >> >> Perhaps something using JMSDestinationRuntimeMBean and
              >> >> JMSServerRuntimeMBean?
              >> >>
              >> >> Oh, just noticed JMSRuntimeMBean.html.getJMSServers(), this might do
              >> >> it. I'll post it nonetheless in case other people have better ideas.
              >> >>
              >> >> Thanks.
              >> >
              >
              

  • What about session memory when using BEA Weblogic connection pooling?

    Hi,
    consider a web application, allowing database connections via a BEA Weblogic 8.1 application server. The app-server is pooling the oracle connections. The oracle database is running in dedicated server mode.
    How are the database requests from the web app served by the connection pool from BEA?
    1) Does one oracle session serve more than one request simultanously?
    2) Does BEA serialize the requests, which means, that a session from the pool is always serving only one request at a time?
    If (1) is true, than what about the session memory of Oracle sessions? I understand, that things like package global variables are beeing stored in this session private memory. If (1) is true, the PL/SQL programmer has the same situation, as with programming an Oracle databas in "shared server" mode, that is, he should not use package global variables etc.
    Thankful for any ideas...
    Message was edited by:
    Xenofon

    Xenofon Grigoriadis wrote:
    Hi,
    consider a web application, using BEA between client and an Oracle Database (v9i). BEA is pooling the oracle connections. The oracle database is running in dedicated server mode.
    How are the database requests from the web app beeing served by the connection pool from BEA?
    1) Does one oracle session serve more than one request simultanously?no.
    2) Or does BEA serialize the requests, which means, that a session from the pool is always serving only one request at a time?
    Reading "Configuring and Using WebLogic JDBC" from weblogic8.1 documentation, I read:
    "... Your application "borrows" a connection from the pool, uses it, then returns it to the pool by closing it...."
    What do you mean by returning the connection by closing it? Tbe server will either return the connection to the pool or close it...When application code does typical jdbc code, it obtains
    a connection via a WebLogic DataSource, which reserves an
    unused pooled connection and passes it (transparently wrapped)
    to the application. The application uses it, and then closes
    it. WebLogic intercepts the close() call via the wrapper, and
    puts the DBMS connection back into the WebLogic pool.
    The reason, why I as an Oracle programmer ask this is, because every session (=connection)
    in Oracle has its own dedicate, private memory for things like global PL/SQL variables.
    Now I want to figure out, if you have to careful in programming your databases, when
    one Oracle session (=connection) is serving many weblogic requests.It is serving many requests, but always serially. Do note however, that we
    also transparently cache/pool prepared and callable statements with the
    connection so repeat uses of the connection will be able to get already-made
    statements when they call prepareStatement() and prepareCall(). These
    long-lived statements will each require a DBMS-side cursor.
    >
    Thankful for any ideas or practical experience...
    Message was edited by:
    mk637Joe

  • Is the 11.1.1.2 software compatible with BEA WebLogic 10.3?

    Hi,
    Does anyone know, is Oracle EPM version 11.1.1.2 compatible with BEA WebLogic 10.3? I know the recommended version is 9.2 MP3 for Windows 32 bit.
    Do we need to get seperate license for WebLogic or is it included in this EPM software bundle?
    Thanks for your answers in advance..!

    Not sure about the licensing, its best to ask someone at Oracle, but I believe when you when automatic deploy 11.1.1.2 apps to Oracle10gR3 Application Server, it is actually referring to the Oracle Weblogic 10.3 Application Server, not the old Oracle (OAS) 10G Application Server, so it should work. You can also deploy to Weblogic 9.2 and IBM Webshpere automatically. I believe all other application servers may still be compatible but require a manual deployment.
    Regards,
    Imran

Maybe you are looking for