This content has been marked as final. Show 3 replies
The unit of homogeneous transparency in WebLogic is almost always a single cluster, or, if non-clustered, a single server.1 person found this helpful
What adapter are you using? The only JMS adapter that's currently packaged with WebLogic is the "Bridge Adapter" plug-in for the Messaging Bridge, and such an adapter can only consume from a single member of a single distributed destination in a single cluster. Of the external adapters I know about, I'm not aware of any that are designed to transparently work with multiple clusters, and I'm only aware of one that's that's specifically has mode capable of transparently ensuring that all members of a distributed destination in a single cluster are serviced (the Oracle "SOA JMS Adapter") . WebLogic MDBs automatically ensure full coverage of WebLogic JMS clustered destinations, but don't use or need an adapter to provide this capability.
I suspect you may be assuming that a multi-address URL defines a unit of transparent access to multiple clusters. This is usually not the case. In most uses, a URL is implicitly used to resolve once to a single server in a single cluster, no matter how many addresses are in the URL. In turn, a JNDI context that's hosted on this server is used to obtain access to potentially clustered resources within the same cluster as the server that hosts the context. The clustered resource references in turn, keep a dynamically maintained list of cluster members so that they can be used to fail-over if need be (clustered resource references are typically EJB "smart stubs" or JMS connection factories).
If your adapter does happen to have some sort of mode that allows it to work with multiple disparate clusters (likely by providing some way to specify multiple URLs), then this mode is enabled in some way that's proprietary to the adapter.
Finally, note that if your adapter can support working with different clusters concurrently, you'll need to make sure that all domain names for different domains are different, and, at least in older versions, that all WL server names are unique even if they are in two different domains. This is a requirement for any two domains that are interoperating, or that are being used by the same remote JVM...
Thanks for responding, but i dint understand much that you explained as i am quite new to SOA. I will try to explain my requirement again.
My cluster environment has one admin server and two managed servers.
In my code, I have a JMS adapter with interaction specification as -
My bpel process when triggered, will consume the messages from a distributed queue. But somehow, though my queue is a uniformed distributed queue, my jms adapter only picks the message from the queue on one managed server. For example, if there are 2 messages on managerserver1 and 3 messages on managedserver2, only 2 messages from managedserver1 are picked up when my bpel composite is triggered. And i expect all 5 messages to be consumed :(
Any inputs are highly appreciated.
Please try posting to a BPEL forum to get specific guidance. Your questions are fairly specific to BPEL and the SOA Adapter, and I have little background in either. I can only hazard an educated guess about what's happening:
To me, the term "ReceiveNoWait" implies the use of a standard JMS synchronous consumer, which is termed an "outbound" API in adapter parlance. My guess is this will probably only be able to attach to and service a single member of a distributed destination - which is the behavior you seem to be getting. I'm not 100% sure if this is expected behavior as I'm not familiar with the SOA Adapter, but this would certainly be the expected behavior if your code was communicating directly with WL JMS instead of indirectly via the adapter.
To ensure full coverage with the SOA adapter of a single distributed queue, I think you need to process messages asynchronously using an inbound asynchronous messaging path. I know the SOA Adapter provides such a mode, but I'm not familiar with the BPEL mechanics of setting this up. Perhaps this requires a standard WebLogic Java EE MDB that uses the SOA Adapter, or perhaps there's some sort of BPEL equivalent to an MDB that uses the adapter. A "pure" WebLogic MDB (no adapter) would also do the trick.
Hope this helps,