JNDI in a cluster
Hi,
I've got a situation where I am deploying two different ears into two different Managed Servers in the same cluster. One ear is trying to look up an ejb from the other ear but for some reason the stateless bean iis not getting published into the JNDI tree of the cluster, and is only visible inside the managed server that the ear is deployed to. My question is: isn't the JNDI tree supposed to be global to all the servers inside of a cluster so registering an ejb in one will make it available to the rest of the cluster?
When you deploy ear file to one of the Managed server's part of cluste, the JNDI name can be seen only in that Managed server's tree, it cannot be seen in cluster JNDI tree or other managed servers JNDI tree.
- - Tarun
Similar Messages
-
What is "Replicate JNDI Name In Cluster" equivalent in Weblogic 10.3
Hi,
We are migrating one of our application from WL8 and WL10.3 where the existing setup using a non-distributed queue with "Replicate JNDI Name In Cluster" enabled. The cluster has 2 instances Ex: M1 and M2, both of these instances are using the aforesaid non-distributed queue which is tragetted only to M1 instance.
However the queue is targetted to M1, JNDI name associated to this Queue is available in M2 server so the MDB and Initial Context lookups are able to obtain the queue instance.
Now the issue is, we are unable to setup this feature in WL10.
1. We have created a UDQ and targetted to only M1.
2. MDBs and Intial context lookups from M2 is failing with NameNotFoundException.
Ultimatey the requirement is, the application deployed on cluster should consume/publish message only to/from queues available in M1. There is business reason behind this.
Please help.Hi,
If your MDB is io version 3.0 then u can make use of the following Annotations to define the "*providerUrl*" of the server from where ur MDB wants to listen the messages.
Example: http://weblogic-wonders.com/weblogic/2010/06/09/mdb-with-non-container-specific-annotations/
initial-context-factory (Equivalent Property: initialContextFactory)
provider-url (Equivalent Property: providerURL)
ActivationConfigProperty(propertyName = “providerURL”, propertyValue = “your_MS1_Address”)
If you are using MDB2.0 then the same thing u need to do with "weblogic-ejb-jar.xml" file using <provider-url > Tag.
Thanks
Jay SenSharma -
Is there a way to force the JNDI replication?
It is on by default, unless you specifically disabled it:
http://e-docs.bea.com/wls/docs61/javadocs/weblogic/jndi/WLContext.html
REPLICATE_BINDINGS
public static final java.lang.String REPLICATE_BINDINGS
Cluster-specific: Specifies whether tree modifications are replicated
and is only applicable when connecting to WebLogic Servers that are running
in a cluster. By default, any modification to the naming tree is replicated
across the cluster, which ensures that any server can act as a naming server
for the entire cluster. Setting this property to false changes this behavior
and should be done with extreme caution: a false setting means that modifications
to the tree caused by bind, unbind, createSubcontext, and destroySubcontext
will not be replicated.
Understand the implications of this property before changing its default (true).
Pothiraj <[email protected]> wrote:
> Is there a way to force the JNDI replication?
Dimitri
-
JNDI Exception on Cluster Redeployment
"Does anyone know what was the resolution on the attached newsgroup posting? i am experiencing a similar
Jerry Davis <[email protected]> wrote:
>"Does anyone know what was the resolution on the attached newsgroup posting?
> i am experiencing a similar
This seems to have gotten chopped. I am seeing the following error when attempting
to hot-deploy (through the admin console) a simple stateless EJB
to the second managed server, and receive this exception. The first managed server
receives the deployment no problem; it's only the second managed
server that throws the exception.
<Jun 14, 2001 4:56:39 PM CDT> <Error> <J2EE> <Error deploying application HelloWorld_EJB:
Could not deploy: 'HelloWorld_EJB.jar': JNDI name in use
>
<Jun 14, 2001 4:56:39 PM CDT> <Error> <Management> <InvocationTargetException
setting attribute Deployed on MBean wwt:Name=HelloWorld_EJB,Location=testlogic2Server,Type=ApplicationConfig
to value true. Method: public void weblogic.management.mbeans.custom.Application.setDeployed(boolean)
throws weblogic.management.DeploymentException,weblogic.management.UndeploymentException
weblogic.management.DeploymentException: Could not deploy: 'HelloWorld_EJB.jar':
JNDI name in use
at weblogic.j2ee.EJBComponent.deploy(EJBComponent.java:35)
at weblogic.j2ee.Application.deploy(Application.java:167)
at weblogic.j2ee.J2EEService.deployApplication(J2EEService.java:173)
at weblogic.management.mbeans.custom.Application.setLocalDeployed(Application.java:217)
at weblogic.management.mbeans.custom.Application.setDeployed(Application.java:187)
at java.lang.reflect.Method.invoke(Native Method)
at weblogic.management.internal.DynamicMBeanImpl.invokeSetter(DynamicMBeanImpl.java:1136)
at weblogic.management.internal.DynamicMBeanImpl.setAttribute(DynamicMBeanImpl.java:773)
at weblogic.management.internal.DynamicMBeanImpl.setAttribute(DynamicMBeanImpl.java:750)
at weblogic.management.internal.ConfigurationMBeanImpl.setAttribute(ConfigurationMBeanImpl.java:256)
at com.sun.management.jmx.MBeanServerImpl.setAttribute(MBeanServerImpl.java:1356)
at com.sun.management.jmx.MBeanServerImpl.setAttribute(MBeanServerImpl.java:1331)
at weblogic.management.internal.RemoteMBeanServerImpl_WLSkel.invoke(RemoteMBeanServerImpl_WLSkel.java:1075)
at weblogic.rmi.internal.BasicServerAdapter.invoke(BasicServerAdapter.java:373)
at weblogic.rmi.internal.BasicServerAdapter.invoke(BasicServerAdapter.java:237)
at weblogic.rmi.internal.BasicRequestHandler.handleRequest(BasicRequestHandler.java:118)
at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:17)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
>
<Jun 14, 2001 4:56:39 PM CDT> <Error> <Cluster> <Conflict start: You tried to
bind an object under the name HelloWorldBean_EO in the jndi tree. The object you
have bound weblogic.rmi.cluster.ClusterableRemoteObject from prodlogic2 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.>
-
How to lookup the remote interface in JNDI of the cluster (glassfish)
I have write a simple sessionbean:
package authority;
import javax.ejb.Stateless;
* Session Bean implementation class LoginSessionBean
@Stateless
public class LoginSessionBean implements LoginSessionBeanRemote, LoginSessionBeanLocal {
* Default constructor.
public LoginSessionBean() {
// TODO Auto-generated constructor stub
@Override
public boolean login(String name, String password)
boolean result = false;
System.out.println("User: " + name + " is login with password: " + password);
return result;
@Override
public LoginSessionBeanRemote create()
// TODO Auto-generated method stub
return this;
}And I write a simple client to test it.
package test;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.rmi.PortableRemoteObject;
import authority.LoginSessionBean;
import authority.LoginSessionBeanRemote;
public class SessionBeanTestClient
public static void main(String[] args)
try
InitialContext context = new InitialContext();
Object obj = context.lookup(LoginSessionBean.class.getName());
LoginSessionBeanRemote loginService = (LoginSessionBeanRemote)PortableRemoteObject.narrow(obj, LoginSessionBeanRemote.class);
loginService.login("Jason", "password");
catch (NamingException e)
// TODO Auto-generated catch block
e.printStackTrace();
}And it is OK, but after I deploy the sessionbean into a cluster with two instances on local host, it can not find the remote interface:
javax.naming.NameNotFoundException: authority.LoginSessionBean not found
at com.sun.enterprise.naming.TransientContext.doLookup(TransientContext.java:216)Is it different for cluster (for IIOP port?), I want to test the HA solution, how could I start it?Please look at http://otn.oracle.com/tech/java/oc4j/htdocs/oc4j-how-to.html. There is a How-To on local interface.
thanks
Debu -
In summary I am having a problem with my application when it is running on the server that does not contain the JMS.
Setup:
2 machines:- Server 1 with the Admin Server and a Managed Server with JMS and a Distributed Queue. Second machine (Server 2) with a managed server. The two managed servers are in a Cluster.
The connection factory has xa enabled.
The queue is a distributed queue, with one member queue - on server 1.
Scenario 1 (works):
Deploy my application on Server 1 only
Scenario 2 (works):
Deploy my application on Server 1 and Server 2
When the application puts messages on the JMS queue, the messages are processed round robin by the MDB on both Server 1 and Server 2 - as expected.
Scenario 3 - Does not work
Deploy my application on Server 2 only
The application successfully sends a message to the queue - I can see it in queue through the console.
However the MDB never processes the message. On the queue, I can see 0 consumers.
Essentially the MDB appears to deploy correctly from the server log but never appears as a consumer on the queue.
I know the above information is very brief, however I can provide more configuration details and detailed logging if required.On a further look through the logs, I have found the following Warning message which may point to the reason why my MDB is not receiving messages from JMS:
<25-Apr-2005 17:26:01 o'clock IST> <Warning> <EJB> <BEA-010220> <The jms destination 'AsyncMessageQueue' is a distributed destination and it has no physical destination(s) on the current weblogic server. As per distributed destination co-location rules, no pool was creted for the MDB 'AsyncMessage(Application: m3-j2ee_Weblogic21apr_2, EJBComponent: ejb_framework.jar)' on this weblogic server. Hence the MDB 'AsyncMessage(Application: m3-j2ee_Weblogic21apr_2, EJBComponent: ejb_framework.jar)' cannot receive any messages on this server.>
I have created a Destination on the JMS Server ("Replicate JNDI Name In Cluster" is set), and I have created a Distributed Destination, which has as its member the Destination associated with the JMS Server.
If the JMS is not on the same server as the deployed application, how do I get the MDB to connect to the physical destination?
Do I always need a Physical Destination on the the same server as my deployed application? If so, how do I create a Physical Destination on the server that does not have the JMS?
Any help appreciated. -
Distributed queue usage with custom queue listeners in cluster
Hi,
Can someone help in solving the issue. We have a web application which will create consumers(threads in infinite loop) for an inbound queue(name comes from DB table) and after doing certain process result will be pushed to outbound queue(name comes from DB table).
When application runs in single managed server(without clustering) every thing works fine.
If I want to deploy the same application in two managed servers (with are under same cluster) which talks to same DB how to handle above scenario
1. Create 2 JMS servers one on each managed server(on different machines)
2. Create queue one for each JMS server
3. Create distributed queue and add above two queues as members of it
4. Create connection factory and target it to cluster
After creating above instrastructure(similar infrastructure will be created for inbound and outbound queue), can I use distributed queue JNDI name to create listeners(threads) to read messages? Or do I need to create listeners for each individual member in the distributed queue?
I know that while sending message to distributed queue, I can create sender on distributed queue and weblogic automatically takes care of sending the message to appropriate member in the DQ, but how it works for distributed queue?
Also, want to know how can I access distributed queue? For example, if managed server 1 is accessed by http://10.11.134.24:7001 and managed server 2 is accessed by http://10.11.134.25:7001. which URL I need use in JNDI context provider URL to access distributed queue? can I use any URL will it make any difference?
Generally for servlets/JSPs we create proxy server to access it through cluster, instead of directly using managed server URLs. But how it works for distributed queue?
Thanks
Santhosh
Edited by: user8676720 on Oct 4, 2011 8:35 AMYes.
It turns out that if replicate local queue jndi name in cluster is set to false
the message did not get forward :(
Dongbo Xiao <[email protected]> wrote:
>Sorry, the attribute is ForwardDelay, not ForwardPolicy.
>
>Dongbo
>
>Dongbo Xiao wrote:
>
>> Hi Eran,
>>
>> Have you set up the ForwardPolicy for the Distributed Queue?
>> By default, the ForwardPolicy is -1, which turns off the forwarding.
>>
>> Dongbo
>>
>> eran wrote:
>>
>> > Hello,
>> > I have 2 nodes in cluster each one has a pinned JMS server with a
>queue QueueA
>> > and QueueA2
>> > respectively both mebers in a distributed destination dist_queue.
>> > There is a consumer on QueueA only (startup class).
>> > In case of a message sent to QueueA2 a consumer is created for QueueA2
>automaticly
>> > (seen in the admin console) out of the blue, and the message do not
>get forward
>> > to QueueA where my consumer is listening.
>> > Monitoring JMS connections of both servers shows only my consumers'
>connection.
>> > Our application depends on the forward feature.
>> > Am I doing something wrong? any ideas?
>> >
>> > Thanks.
>> > Eran
>
-
RMI callbacks with no replica aware stubs in a cluster?
We would like to use either an RMI ping mechanism or an RMI callback in an upcoming project but are limited to 1.1 and 1.2 JRE's. I don't believe generating a replica aware proxy is an option for us given those constraints, no support for dynamic proxies. So we have a remote server object that we would ideally like to be clusterable that we can register a callback interface with. How can we accomplish this given our client limitations with weblogic 8.1 RMI? Any options?
Yep you speak no lies. Of course once I thought about it some more I realized the error of assuming one could register a jdk rmi object with a weblogic rmi object. JRMP vs T3?. Not good.
We still like using plain jane RMI w/in weblogic. I can register my UnicastRemoteObject stub with a normal RMI object on the server and it can callback and deliver messages. It will also send heartbeats periodically. If the heartbeat isn't heard from in awhile we re-register through http. The advantage of this is that the http session has failed over to another box and the web tier manages the rmi registration for me. The client can remain ignorant of any RMI lookups, which are tedious when not using JNDI or the cluster aware proxy.
All of this to get back a few seconds and keep a few thousand clients from polling through a servlet every second. Argh JDK 1.1.
Thanks for hammering that final point in. -
When I do a:
Context context = new InitialContext();
In a clustered environment, will that connect to the cluster JNDI or the
localhost JNDI?
We need to make sure whenever our stateless session beans get a handle
to the context, it is the localhost JNDI, Is there a way to do this if
the answer to the above question is the cluster?
The problem we have is we are binding local objects into JNDI, each
server in the cluster needs to get references to one of these objects
(the stateless session bean needs to do a lookup and get a reference).
So our code looks something like this:
public class MyStatelessSessionBean implements SessionBean
public void myRemoteCall(...) throws RemoteException
Context context = new InitialContext();
MyLocalObject object = (MyLocalObject)context.lookup("MyObject");
We need to ensure that the MyLocalObject that is returned is one from
the localhost, not one in the cluster.
thanks,
-chris
On the server if you do a Context ctx = new InitialContext() it will return you
local initial context. So, your lookup will be local.
Instead if you use a dns cluster name then the first server name that dns server
returns will be used to connect and get an initial context if you are on a
standalone client.
Environment env = new Environment();
env.setProviderUrl("t3://fooclust:7001");
Context ctx = env.getInitialContext()
When you do a lookup in the jndi tree, what you get back depends on the server
configuration and doesn't depend on where you look if you are in a homogenous
cluster.
- Prasad
Chris Humphrey wrote:
> Thanks for the reply. We are currently using the Referenceable interface to
> store and get objects from jndi, so the objects are not serializable.
>
> It sounds like I have a problem to fix here, let me recap to make sure I
> understand. If the bean was accessed with a DNS cluster for the context, I
> will get back a reference to the cluster, if the bean was accessed using
> 'localhost' I will get back a reference to the jndi running locally.
>
> This was what I was afraid of. Is there a way to forceably get an initial
> context to the localhost jndi?
>
> Thanks again for the reply.
> -chris.
>
> Wei Guan wrote:
>
> > Comments inline
> >
> > --
> > Hope it helps.
> >
> > Cheers - Wei
> >
> > "Chris Humphrey" <[email protected]> wrote in message
> > news:[email protected]...
> > > When I do a:
> > >
> > > Context context = new InitialContext();
> > >
> > > In a clustered environment, will that connect to the cluster JNDI or the
> > > localhost JNDI?
> > In cluster, JNDI tree is "replicated JNDI tree". Every server in the
> > cluseter has the same "replicated JNDI tree".
> > " Context context = new InitialContext();" will give you reference to the
> > JNDI tree in the same JVM as the caller's.
> >
> > >
> > > We need to make sure whenever our stateless session beans get a handle
> > > to the context, it is the localhost JNDI, Is there a way to do this if
> > > the answer to the above question is the cluster?
> > >
> > > The problem we have is we are binding local objects into JNDI, each
> > > server in the cluster needs to get references to one of these objects
> > > (the stateless session bean needs to do a lookup and get a reference).
> > >
> > > So our code looks something like this:
> > >
> > > public class MyStatelessSessionBean implements SessionBean
> > > {
> > > public void myRemoteCall(...) throws RemoteException
> > > {
> > > Context context = new InitialContext();
> > > MyLocalObject object = (MyLocalObject)context.lookup("MyObject");
> > > }
> > > }
> > >
> > > We need to ensure that the MyLocalObject that is returned is one from
> > > the localhost, not one in the cluster.
> > If your "MyObject" is a serializable object, serializable objects binding
> > the JNDI tree will be replicated. That is, "MyObject" will have a copy on
> > each server's JNDI tree. Since you get JNDI reference from localhost, your
> > lookup("MyObject") will get the copy in the same JVM.
> >
> > >
> > > thanks,
> > > -chris
> > >
-
Load balance with JMS in cluster
I would like to develop a MDB listening to a topic, which can be deployed in a
weblogic cluster, so that whenever a message is published to that topic, one and
only one of the MDB in a wls server of the cluster will process the message, what
is the best way to do this?
thanks
Zhou
Do you desire a distributed topic that doesn't replicate
between topic members, but replicates
to all subscribers on a particular member?
If so, then a distributed topic is NOT
what you want to configure. Instead, you can do as you
suggest: set JNDINameReplicated to false
and put a same JNDI named topic on each server.
Tom
Tom Barnes wrote:
>
>
> x zhou wrote:
>
>> Can I do the following to achive what I want:
>
>
> I don't know what you want. But a message sent to a topic
> member still gets replicated to the other topic members.
>
> I'm guessing what you are looking for is a
> distributed queue, not a distributed topic. I suggest
> you look at the distributed queue option. A message
> sent to a distributed queue will only get processed
> by one MDB.
>
>>
>> 1) create a distributed topic having topic name "topic.distributed"
>> that has "topic.1"
>> and "topic.2" as its member on two wls instances in a cluster
>>
>> 2) write a MDB that will be deployed seperately to 2 wls instances in
>> the cluster,
>> with different weblogic-ejb-jar.xml file: the difference is at the line:
>>
>> <destination-jndi-name>topic.1</destination-jndi-name> for server 1;
>> <destination-jndi-name>topic.2</destination-jndi-name> for server 2;
>>
>> 3) create the publisher using the distributed topic (of jndi name
>> 'distribute.topic'),
>> according the document, it should send the message to one and only one
>> of its
>> member, and therefore the corresponding MDB in the wls instance of the
>> cluster
>> which receives the message will be notified
>>
>> and this will give me multi-threading in the same wls instance
>> (because of MDB)
>> and load-balancing across the whole cluster, right?
>>
>> Incidently, it looks like I can make the topic member's jndi name the
>> same, as
>> long as I un-check the "Replicate JNDI Name In Cluster" checkbox. Why
>> is there
>> such a box in the first place? Isn't the topic not clusterable?
>>
>> thanks
>>
>>
>> Tom Barnes <[email protected]> wrote:
>>
>>> (1) Currently, there is no way in WL to get multiple consumers to share
>>> a topic subscription - which is essentially what you are asking for.
>>> The JMS standard doesn't support this either. This is not to say
>>> that it wouldn't be a useful feature - I personally think it would be.
>>>
>>> (2) Why not use a queue?
>>>
>>> Tom
>>>
>>> X Zhou wrote:
>>>
>>>
>>>> I would like to develop a MDB listening to a topic, which can be
>>>> deployed
>>>
>>>
>>> in a
>>>
>>>> weblogic cluster, so that whenever a message is published to that
>>>> topic,
>>>
>>>
>>> one and
>>>
>>>> only one of the MDB in a wls server of the cluster will process the
>>>
>>>
>>> message, what
>>>
>>>> is the best way to do this?
>>>>
>>>> thanks
>>>>
>>>> Zhou
>>>
>>>
>>
>
-
Hi Don ,
All the manager servers in a cluster send heartbeat messages to each other
using multicast adress) after a certain time period ( i.e every 10 sec ) ,
at that time it updates their local JNDI tree .
When we do clustering and a new object object get bound to a cluster then
that object's JNDI will be replicated to all the server's in the cluster .
Thanks and regards
Johnny
"Don Ferguson" <[email protected]> wrote in message
news:[email protected]...
> We are using ip-multicast to propogate the JNDI information to other
> servers in the cluster. I believe the update is sent immediately
> (rather than batched and refreshed periodically) but I'm not sure what
> the propogation delay.
>
> matt wrote:
> >
> > Selvan,
> > My understanding is that by default all objects registered to JNDI will
be
> > clustered unless you specify a "do not cluster" property in the
> > properties file. The exact property can be found in the API doc for
JNDI.
> > Sunil
> >
> > Selvan Ramasamy <[email protected]> wrote in message
> > news:[email protected]...
> > > Hello,
> > >
> > > If I do cluster few servers then what about the objects I bind them in
the
> > > JNDI.
> > > how frequently these JNDI get reflected to all the cluster servers.
> > > I am going to do some caching for my clients by binding some java
> > classes
> > > in the JNDI.
> > >
> > > I think that I am not clear about JNDI bindings with cluster.
> > >
> > > Please help me out what exactly happens when do clustering and a new
> > object
> > > get bound in the JNDI.
> > >
> > > Thanks
> > > /selvan
> > >
> > > Selvan Ramasamy
> > > Captura Software Inc
> > >
> > >
> > >
-
Connection Factories in a Cluster
Hi Folks,
I'm trying to get to grips with the precise behavior of connection factories
(CF) in a cluster. Any corrections/additions appreciated...(I've read the
perf. guide).
According to the docs, you should look at two scenarios
a) JMS app located on same server as cluster.
Imagine I have a JMS app deployed to the cluster, and docs say I should
deploy CF to cluster as well.
I have JMS server only on one server in the cluster.
Here is what I think happens:
i. As far as I know, connection factories will only load balance
connections across servers hosting connection factories.
ii. When the app looks up a CF using the JNDI of the cluster, will it
always get the a CF collocated
with the app (ie. on same server), because of collocation optimization?
iii. When the app uses this CF to create a Connection, will the CF load
balance the connection?
ie. Will I get a different connection (round robin) every time I
create a connection?
If this does happen, then presumably my JMS application will route
all JMS traffic through this connection to this other
server, which may not even host a JMS server, which in turn has to
route to the JMS server.
iv. If the CF was looked up using the local JNDI context, then the
local CF will be returned and presumably if
I create a connection then a local connection will be returned. ie.
no load balancing. The JMS application will
use the "local" connection which will in turn route to the
appropriate server hosting the JMS server..
b) Where the JMS client is external
When I have an external JMS client, the docs say you should deploy the CF
only to those servers hosting the JMS servers.
i) The docs say that the CF (new InitialContext("t3://clusteraddres"))
will load balance across the servers in the cluster.
ii) The docs also say that createConnection (on the CF) will load balance
too.
iii) This means that there are two servers involved right? The CF host
(the server hosting the CF), and the C host (the
server hosting the C). Does this mean I have two connections from
teh client (one to each server), or does traffic
flow from client to CF host to C host?
The docs certainly imply that you get these two load balancing
operations, which seems to lead to one of these
scenarios.
iii) Presumably, if my client creates multiple connections (one after the
other) using the same connection factory,
then it may at one time have a connection going to "ServerA", and at
another time one going to "ServerB" (unless
of course I have affinity enabled).
Any guidance appreciated,
Regards,
Jon
Jon Mountjoy wrote:
> Hi Tom,
>
> I have inlined some comments on your comments!
>
>
>>>a) JMS app located on same server as cluster.
>>> Imagine I have a JMS app deployed to the cluster, and docs say I
>
> should
>
>>>deploy CF to cluster as well.
>>> I have JMS server only on one server in the cluster.
>>>
>>> Here is what I think happens:
>>> i. As far as I know, connection factories will only load balance
>>>connections across servers hosting connection factories.
>>
>>Yes.
>>
>>> ii. When the app looks up a CF using the JNDI of the cluster, will
>
> it
>
>>>always get the a CF collocated
>>> with the app (ie. on same server), because of collocation
>
> optimization?
>
>>Yes.
>>
>>> iii. When the app uses this CF to create a Connection, will the CF
>
> load
>
>>>balance the connection?
>>
>>Not if it is collocated.
>
>
> I guess this confuses me a little. My scenario above speaks about the
> CF+App deployed to a cluster.
>
> Are you talking about if the CF+App is collocated with the JMS server whose
> destination the App is communicating with?
No.
> (I'd guess not, cos I wouldn't
> know the destination until after I create the connection?).
If the app is co-located with the the CF, the connection
is always local.
>
>
>>(Note that a producer to a distributed destination,
>>by default produces to the local physical instance,
>>and will not round-robin each message to other
>>physical destination instances, unless the
>>connection factory is so configured.)
>>
>>
>>> ie. Will I get a different connection (round robin) every time I
>>>create a connection?
>>> If this does happen, then presumably my JMS application will
>
> route
>
>>>all JMS traffic through this connection to this other
>>> server, which may not even host a JMS server, which in turn has
>
> to
>
>>>route to the JMS server.
>>> iv. If the CF was looked up using the local JNDI context, then the
>>>local CF will be returned and presumably if
>>> I create a connection then a local connection will be returned.
>
> ie.
>
>>>no load balancing. The JMS application will
>>> use the "local" connection which will in turn route to the
>>>appropriate server hosting the JMS server..
>>
>>Yes.
>>
>>
>>>b) Where the JMS client is external
>
>
>
>>> iii) This means that there are two servers involved right? The CF host
>>>(the server hosting the CF), and the C host (the
>>> server hosting the C). Does this mean I have two connections
>
> from
>
>>>teh client (one to each server),
Yes. But not for the reason you think.
The JNDI context that was used to look up
the CF keeps its connection, and the JMS
connection generated from the CF.
>>> or does traffic
>>> flow from client to CF host to C host?
Yes.
>>> The docs certainly imply that you get these two load balancing
>>>operations, which seems to lead to one of these
>>> scenarios.
>
>
> Can you perhaps shed some light on the above question?
>
>
>>>Any guidance appreciated,
>
>
>>Just send a portion of your book royalties. ;-)
>
>
> Hehe. Do you think I'd actually make a profit!? What you will earn, is my
> eternal gratitude of course :)
>
> Regards,
> Jon
>
>
-
HeartbeatMonitorListener fails
I get this exception when weblogic starts up and connects to the queue. I think
i am getting the problem as i don't have license for jms cluster. It doesn't help
even when i turn off "Replicate JNDI name on cluster" option. So any idea to fix
this problem will be helpful.
[weblogic] [EJB:010196]'weblogic.jms.common.JMSException: Error creating session'
Linked exception = 'weblogic.jms.disp
atcher.DispatcherException: Could not register a HeartbeatMonitorListener for
[weblogic.jms.dispatcher.DispatcherImpl@1c
aefb0] for myserver'
[weblogic] weblogic.jms.common.JMSException: Error creating session
[weblogic] at weblogic.jms.frontend.FESession.setUpBackEndSession(FESession.java:792)
[weblogic] at weblogic.jms.frontend.FESession.consumerCreate(FESession.java:1031)
[weblogic] at weblogic.jms.frontend.FESession.invoke(FESession.java:2527)
[weblogic] at weblogic.jms.dispatcher.Request.wrappedFiniteStateMachine(Request.java:609)
[weblogic] at weblogic.jms.dispatcher.DispatcherImpl.dispatchSync(DispatcherImpl.java:153)
[weblogic] at weblogic.jms.client.JMSSession.consumerCreate(JMSSession.java:1768)
[weblogic] at weblogic.jms.client.JMSSession.createConsumer(JMSSession.java:1615)
[weblogic] at weblogic.jms.client.JMSSession.createReceiver(JMSSession.java:1454)
[weblogic] at weblogic.ejb20.internal.JMSConnectionPoller.setUpQueueSessions(JMSConnectionPoller.java:1594)
[weblogic] at weblogic.ejb20.internal.JMSConnectionPoller.createJMSConnection(JMSConnectionPoller.java:1806)
[weblogic] at weblogic.ejb20.internal.JMSConnectionPoller.connectToJMS(JMSConnectionPoller.java:1072)
[weblogic] at weblogic.ejb20.internal.JMSConnectionPoller.trigger(JMSConnectionPoller.java:958)
[weblogic] at weblogic.time.common.internal.ScheduledTrigger.run(ScheduledTrigger.java:243)
[weblogic] at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
[weblogic] at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:97)
[weblogic] at weblogic.time.common.internal.ScheduledTrigger.executeLocally(ScheduledTrigger.java:229)
[weblogic] at weblogic.time.common.internal.ScheduledTrigger.execute(ScheduledTrigger.java:223)
[weblogic] at weblogic.time.server.ScheduledTrigger.execute(ScheduledTrigger.java:49)
[weblogic] at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:178)
[weblogic] at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:151)
[weblogic] Caused by: weblogic.jms.dispatcher.DispatcherException: Could not
register a HeartbeatMonitorListener for [w
eblogic.jms.dispatcher.DispatcherImpl@1caefb0] for myserver
[weblogic] at weblogic.jms.dispatcher.DispatcherManager.dispatcherCreate(DispatcherManager.java:306)
[weblogic] at weblogic.jms.dispatcher.DispatcherManager.dispatcherFindOrCreate(DispatcherManager.java:354)
[weblogic] at weblogic.jms.frontend.FESession.setUpBackEndSession(FESession.java:790)
[weblogic] ... 19 more
[weblogic] Caused by: weblogic.rmi.extensions.server.HeartbeatMonitorUnavailableException:
Could not register a Heartbe
atMonitorListener for [weblogic.jms.dispatcher.DispatcherImpl@1caefb0]
[weblogic] at weblogic.rmi.extensions.server.HeartbeatMonitor.addHeartbeatMonitorListener(HeartbeatMonitor.java:86)
Hi,
I don't know what you mean by "don't have
a license for JMS cluster". If you have a license
that enables JMS, then you get all JMS features.
And, since the stack trace below shows you are
deploying an MDB, then you must have a license
that enables JMS: there is no such thing as an EJB
capable server that is not also JMS capable.
I find the stack trace curious. My only guess is
a network issue - are you specifying a URL in
the weblogic descriptor? There is no need
if JMS is running in the same server (or same
cluster) as the MDB.
If you like, post your config.xml and
your descriptor files and I'll take a quick
look.
Tom, BEA
"Satyabrata Dash" <[email protected]> wrote:
>
>I get this exception when weblogic starts up and connects to the queue.
>I think
>i am getting the problem as i don't have license for jms cluster. It
>doesn't help
>even when i turn off "Replicate JNDI name on cluster" option. So any
>idea to fix
>this problem will be helpful.
>
>
> [weblogic] [EJB:010196]'weblogic.jms.common.JMSException: Error creating
>session'
>Linked exception = 'weblogic.jms.disp
>atcher.DispatcherException: Could not register a HeartbeatMonitorListener
>for
>[weblogic.jms.dispatcher.DispatcherImpl@1c
>aefb0] for myserver'
> [weblogic] weblogic.jms.common.JMSException: Error creating session
> [weblogic] at weblogic.jms.frontend.FESession.setUpBackEndSession(FESession.java:792)
> [weblogic] at weblogic.jms.frontend.FESession.consumerCreate(FESession.java:1031)
> [weblogic] at weblogic.jms.frontend.FESession.invoke(FESession.java:2527)
> [weblogic] at weblogic.jms.dispatcher.Request.wrappedFiniteStateMachine(Request.java:609)
> [weblogic] at weblogic.jms.dispatcher.DispatcherImpl.dispatchSync(DispatcherImpl.java:153)
> [weblogic] at weblogic.jms.client.JMSSession.consumerCreate(JMSSession.java:1768)
> [weblogic] at weblogic.jms.client.JMSSession.createConsumer(JMSSession.java:1615)
> [weblogic] at weblogic.jms.client.JMSSession.createReceiver(JMSSession.java:1454)
> [weblogic] at weblogic.ejb20.internal.JMSConnectionPoller.setUpQueueSessions(JMSConnectionPoller.java:1594)
> [weblogic] at weblogic.ejb20.internal.JMSConnectionPoller.createJMSConnection(JMSConnectionPoller.java:1806)
> [weblogic] at weblogic.ejb20.internal.JMSConnectionPoller.connectToJMS(JMSConnectionPoller.java:1072)
> [weblogic] at weblogic.ejb20.internal.JMSConnectionPoller.trigger(JMSConnectionPoller.java:958)
> [weblogic] at weblogic.time.common.internal.ScheduledTrigger.run(ScheduledTrigger.java:243)
> [weblogic] at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
> [weblogic] at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:97)
> [weblogic] at weblogic.time.common.internal.ScheduledTrigger.executeLocally(ScheduledTrigger.java:229)
> [weblogic] at weblogic.time.common.internal.ScheduledTrigger.execute(ScheduledTrigger.java:223)
> [weblogic] at weblogic.time.server.ScheduledTrigger.execute(ScheduledTrigger.java:49)
> [weblogic] at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:178)
> [weblogic] at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:151)
> [weblogic] Caused by: weblogic.jms.dispatcher.DispatcherException: Could
>not
>register a HeartbeatMonitorListener for [w
>eblogic.jms.dispatcher.DispatcherImpl@1caefb0] for myserver
> [weblogic] at weblogic.jms.dispatcher.DispatcherManager.dispatcherCreate(DispatcherManager.java:306)
> [weblogic] at weblogic.jms.dispatcher.DispatcherManager.dispatcherFindOrCreate(DispatcherManager.java:354)
> [weblogic] at weblogic.jms.frontend.FESession.setUpBackEndSession(FESession.java:790)
> [weblogic] ... 19 more
> [weblogic] Caused by: weblogic.rmi.extensions.server.HeartbeatMonitorUnavailableException:
>Could not register a Heartbe
>atMonitorListener for [weblogic.jms.dispatcher.DispatcherImpl@1caefb0]
> [weblogic] at weblogic.rmi.extensions.server.HeartbeatMonitor.addHeartbeatMonitorListener(HeartbeatMonitor.java:86)
-
Putting a WebLogic domain on a DMZ
Hi,
We're in the middle of a project at the moment where we are going to put a WebLogic domain which has a cluster, on a DMZ.
One question which has come up time again, is where do you put the WebLogic Admin server for that domain?? Do you put it on the DMZ with the managed servers?? Or is it better practice to put it internally behind a firewall and open up the TCP ports and multicast for the cluster traffic for JNDI updates and cluster heart beats.
Some say leave it on the DMZ, some say put it behind the firewall.
Alistair.What is the harm of keepin Admin Server within the sam DMZ as d othr managed instances?
I feel it should be within the same DMZ as the other Managed instances.. apart frm cluster hearbeats, jndi updates, the LDAP replication also happens.
Share ur thoughts as well...
For authentication will u b using the embedded ldap or some external store? -
Hello:
In a cluster with nodes from different subnet ( with weblogic 7.0 sp1)
there is an application deployed with mdb's. The jms server is not
clustered and is targetted only on one server in the cluster.
When the second node is starting, it is not able to comminicate with the
jms server running in the other node. The connection factories are
clustered.
What I may be doing wrong.
regards,
Ravi
I suggest reading the cluster documentation,
and posting questions to the clustering or jndi newsgroup.
Cluster configuration is outside the scope of JMS per se.
Ravi Krishnamurthy wrote:
> Hello:
> If the cluster multicast address is set to default it works fine. When it is
> set to 239.192.24.123 it does not work.
>
> regards,
> Ravi
>
> Ravi Krishnamurthy wrote:
>
>
>>Hello:
>>In a cluster with nodes from different subnet ( with weblogic 7.0 sp1)
>>there is an application deployed with mdb's. The jms server is not
>>clustered and is targetted only on one server in the cluster.
>>
>>When the second node is starting, it is not able to comminicate with the
>>jms server running in the other node. The connection factories are
>>clustered.
>>
>>What I may be doing wrong.
>>
>>regards,
>>Ravi
>
>
Maybe you are looking for
-
The report can not retrieve the data from the DB
Dear all, I am facing a problem is that i have ready designed reports in Crystal. While refreshing the report in Crystal, it gives an error that it can not retrive the information from the database. But, if i am using the application which the report
-
How to have a text box expand to next page
I already got the text field to expand after i am able to type but when I go to preview the field does not flow to the next page. It hides behind the content I have on page two. How do I get the text field to push the content below it when it expands
-
LR3 bug: Files from a folder with name ending with "." (dot) cannot be imported
This is a weird one Surprisingly, directories with names ending with a dot, don't show in the Import dialog and also cannot imported by using synchronization. So, if you have any folder named "Flowers, trees etc." ... you cannot import it.
-
Message_type_x short dump while deleting request from infocube
Hi, While deleting one of the erroneous requests from some infocubes, system is resulting in short dump "MESSAGE_TYPE_X". This is happening only with respect to some infocubes. Description of short dump: Short text of error message:
-
Where to place Servlets in Tomcat 4.0?
I just recently installed Tomcat on Win2000 and came across a little problem. What is the directory in Tomcat 4.0 to place servlets in? They seem to work fine if they are in 'examples' or in a package within the 'examples'-folder but they do not seem