Remote EJB call between IBM Websphere standalone JVM's on same host - websphere

I have 2 standalone IBM WebSphere server running on same host. Both the servers have same EJB deployed but our code is distributed among 2 EAR's as ClientAgent and services respectively. When calling any service method from clientAgent i.e an EJB call from serverA to serverB it fails with classnotfound error. I opened the NamingService trace to diagnose the problem and found that ServerB is using same JNDI namespace as ServerA.
How can I make ServerB to use its own JNDI name space ?
Note :- With ServerA and ServerB on different hosts, everything works fine.
Thanks
Shivam

Your question does not seem to be clear. You have stated "The Server B is using the same JNDI namespace as server A"
What do you mean by that?
Each server has its own JNDI space where the EJBs and other resources or registered.
Notice that you typically connect to the bootstrap port of a server to connect to the JNDI namespace. The default is 2809, chances are Server A's bootstrap port is 2809.
Server B would have a different one say 2810 and your client code should be connected to this port.
I am guessing that your code does a localhost:2809 which connects it to the Server A.
If you elaborate your problem clearly people can possibly help you out.
HTH
Manglu

Related

MDB unable to connect Foreign Server destination in Weblogic 12c Cluster

I have deployed EAR in Weblogic 12c server targeting a cluster. Here cluster comprises of 2 managed servers on same physical machine.
Now, as per my requirement the application consumes messages from foreign destination e.g. MQ Series, so I have an MDB in my application that should make connection to remote queue via JNDI lookup.
So, in order to fulfill this, I have perfomed following steps:
1) Created a JMS server which targets to cluster.
2) Created a JMS Module which targets to cluster.
3) Inside JMS module created a Foreign server and checked on option - "Default Targeting Enabled". So, it is also targetting to cluster same as its parent.
4) Inside Foreign server, I have created destination and connection factories.
After making above changes, when I tried to deploy my EAR, I am getting following error messages. My MDB is not making connection to destination message queue.
The Message-Driven EJB TestMDB is unable to connect to the JMS destination jms/TEST_FEED_QUEUE. The Error was:
The destination for the MessageDrivenBean TESTMDB could not be resolved at this time. Please ensure the destination is available at the JNDI name jms/TEST_FEED_QUEUE. The EJB container will periodically attempt to resolve this MessageDrivenBean destination and additional warnings may be issued.
Similar errors were displayed on other managed server as well.
Please suggest, where I am doing wrong. Please suggest.

Can someone explain MQSeries file based JNDI for remote client JMS access

I've been searching extensively for a description of how to set up JMS access from a remote client to a file based JNDI MQ Series provider without success.
My JMS client works Ok on the same Linux machine as my MQSeries 7.5 server using file based JNDI.
How does one set up a remote client to use file based JNDI? Is it even possible or must one use LDAP?
I've seen hints that one should be able to have a remote client but nothing very clear.
I'm using Spring JMSTemplate which uses a provider url. On the same machine my Tomcat context.xml file uses a file: fileName url which, as I say, works ok collocated with the MQSeries server.
Thanks
Not a problem. If you are using a File based JNDI then you just need to add a QCF that contains the appropriate information for the remote queue manager. i.e. hostname, port # and channel name
DEFINE QCF(myQCF) QMANAGER(MQWT1) CHANNEL(TEST.CHL) HOSTNAME(22.22.22.22) PORT(1414) TRANSPORT(CLIENT) FAILIFQUIESCE(YES)
I was assuming that there was more than there is to file based JNDI. All it is is reading a property file. Using the "file"" url format allows you to read remote files.

Deploy MDB on WebLogic 10.3

I am new to MDB, so my questions may sound simple.
I implemented an MDB( serving as a Consumer ) using JDeveloper 11.1.7 and built a JAR file using deployment functionality. Now I need to deploy it to WebLogic 10.3 app server. I have several questions:
1) Should I deploy it as a library or as an application?
2) After I successfully deploy and it's in the "RUNNING" mode I assume it should be listening to the particular Queue I specified as a Resource in my MDB implementation. Is that correct?
3) When implementing an MDB all the examples only specify the "destination" but not the "ConnectionFactory". How does it know where to connect to?
Should I deploy it as a library or as an application?
Deploy as an application since the MDB will likely contain business logic specific to the app.
After I successfully deploy and it's in the "RUNNING" mode I assume it
should be listening to the particular Queue I specified as a Resource
in my MDB implementation. Is that correct?
Yes, if your JMS provider is local, specify the name bound in the local JNDI tree for the destination using destination-jndi-name.
When implementing an MDB all the examples only specify the
"destination" but not the "ConnectionFactory". How does it know where
to connect to?
If the MDB is consuming messages from the local WebLogic JMS provider, the container manages configuration for the connections and sessions automatically, so don't set provider-url, initial-context-factory, or connection-factory-jndi-name, unless you have a custom factory to use.
Refer to WebLogic 10.3 documentation for details:

How websphere server creates and manages JMS resources internally

When we set up a queue connection factory, a topic connection factory, a queue, a topic in websphere application server throguh the console, what exactly happens?
The server stores the configuration details in an xml and at server startup, it creates the connection factory(ies), topic(s),queue(s) and puts them in a pool?
I ask because the actual queue(s) and topics(s) itself do not reside on the App server, they reside on a separate (remote) websphere MQ server. So why do we need to 'create' the queues in Websphere App server?
The configuration is metadata for connecting to the remote objects. When the server starts (or an app restarts, or configuration is refreshed), the server reads the .xml, then binds Reference objects into JNDI. The actual connection factories aren't created/pooled until the Reference is first looked up.
I don't have enough experience with JMS to answer your second question, but presumably the metadata is required for the queue in order to access it remotely.

EJB Reference Configuration Error

I have 2 ears—say, Ear1 and Ear2—for my application, which are deployed in clusters. Ear2 is having Ejb which is being called from Ear1. EJB reference is required for communication between Ear2 and Ear1. I am setting the below value to
Target Resource JNDI Name: corbaloc::ClusterServer1:2810,:ClusterServer2:2810/cell/clusters/Cluster1/ejb/com/mycompanyName/projectName/ejb/facade/EjbFacadeHome
But I am getting the below error:
Caused by: javax.naming.ServiceUnavailableException: A communication failure occurred while attempting to obtain an initial context with the provider URL: "corbaloc::mums00100251.in.net.intra:2810,:mums00100392.in.net.intra:2810/cell/clusters/Cluster1/ejb/com/bnpparibas/tradefinance/ejb/facade/EjbFacadeHome". Make sure that any bootstrap address information in the URL is correct and that the target name server is running.
Please help.
The correct format for referencing remote EJB with WebSphere Application Server 6.1 in this case would be like:
corbaloc:iiop:mums00100251.in.net.intra:2810/ejb/com/bnpparibas/tradefinance/ejb/facade/EjbFacadeHome,iiop:mums00100392.in.net.intra:2810/ejb/com/bnpparibas/tradefinance/ejb/facade/EjbFacadeHome
2810 suggests you attempted to use either the bootstrap port of node agents or deployment manager. I would check the ports (you can find the BOOTSTRAP port from the management console under Ports section of the server preferences), and if they still fail use the actual application servers' bootstrap ports.
There could also be a scoping issue which would mandate that. If you deployed your application to the Cluster scope it is possible that the naming service only in the cluster members can actually resolve the EJB.

Resources