Our application is using JSP in front end, webMethods Server as middleware and Oracle at the backend. We are sending request to webMethods using BrokerClient; however, when concurrent users are using this Broker Client, the returned canonical is not the one intended for a particular user. Is there a way to check which canonical should go with the request?
Can you provide a bit more info?
I assume the client is publishing and event. Is it expecting a reply? In other words, is it calling publishRequestAndWait?
Is the published event configured to deliver a reply or publish it? If publish, the reply will go to all subscribers and publishRequestAndWait won’t work.
Is each instance of the broker client connecting to the broker getting its own queue? If not, replies for publishes from all clients will be intermingled in the single shared queue.
This response is from Bob Richardson of Conexus:
The request/reply protocol requires the request to set the _env.tag field to
a value that identifies the request. This value will be returned in the
_env.tag field (assuming that the adapter/server has properly implemented
the protocol). The requestor should match the request tag with the reply tag
to match the request with its reply. webMethods supplies several convenience
APIs for doing request/reply. These APIs automate setting and matching the
tags. Unfortunately, some of the APIs are not thread safe…
“The request/reply protocol requires the request to set the _env.tag field to a value that identifies the request.”
wM-supplied adapters, such as the Oracle DB adapter, do this. Also, the API provides a method for easily creating a reply event within broker clients.
“The requestor should match the request tag with the reply tag to match the request with its reply.”
The publishRequestAndWait method does this.
To address Rahul’s question we need to know how the broke client is connecting to the broker and how it is publishing and waiting for the reply. There are many ways to do this, each with its own issues/gotchas.
Hi,
Thanks a lot for your suggestion.
We were able to resolve our problem.
and had to make two changes in our application.
First
Instead of using
COMSBrokerClient = COMSBrokerClient.newOrReconnect(cHost, brokerName, userId, clientGroup, “COMSJavaClient”, new BrokerConnectionDescriptor());
to create a BrokerCLient now we are using this method
COMSBrokerClient = new BrokerClient(cHost, brokerName,“”,clientGroup,“COMSJavaClient”, new BrokerConnectionDescriptor ());
Second
In webMethods
Instead of publish step in Integration Component we are usig output step.
These two changes solved our problem but Performance has been hit.
May be if you could suggest some other way , It would be a great help.
Here are the answers to your queries
I assume the client is publishing and event. Is it expecting
a reply? In other words, is it calling
publishRequestAndWait?
Yes,Client is publishing an event and we are using publish() to do that
objEvent = new BrokerEvent(COMSBrokerClient, userEvent);
objEvent.setTag(COMSBrokerClient.makeTag());
COMSBrokerClient.publish(objEvent);
where “COMSBrokerClient” is the client we created using BrokerClient()
and “userEvent” is the document we publish
Is the published event configured to deliver a reply or
publish it? If publish, the reply will go to all subscribers
and publishRequestAndWait won’t work.
Earlier we were using publish in webMethods however after
this problem we are using an output step in webMethods
which has solved our problem.
Is each instance of the broker client connecting to the
broker getting its own queue? If not, replies for publishes
from all clients will be intermingled in the single shared
queue.
Since each connection was unique, each Broker was getting its own queue.
Thanks
COMSBrokerClient = COMSBrokerClient.newOrReconnect(cHost, brokerName, userId, clientGroup, “COMSJavaClient”, new BrokerConnectionDescriptor());
This should work just fine, as long as userId is unique among all users and is consistent from connection to connection. What you may have been seeing is old replies/events held in the queue that weren’t retrieved. However, your new approach, allowing the Broker to create a unique client identifier, is the proper approach for request/reply operations.
For your COMSBrokerClient.publish(objEvent); call, is there a reason you’re not using publishRequestAndWait(objEvent, timeout)?
“Since each connection was unique, each Broker was getting its own queue.”
Just to clarify: Having an instance of a BrokerClient object does not imply a unique queue for that client on the Broker (I know that’s not what you meant, but just clarifying for those who may not be familiar with this). The clientId parameter to the BrokerClient constructor identifies the queue on the broker. Multiple BrokerClient objects can specify the same clientId parameter, thus sharing the queue (assuming sharing is enabled).
Regarding the performance: are you creating and destroying the connection for every request? You might consider broker connection pooling.
Glad you got things working right!
I am currently having this same problem. I am successfully triggering the subscribing service, the subscribing service successfully publishes the REPLY, but the publishandwait service keeps on waiting until it times out. Jenny (or) Jay , can you tell me if you solved the problem? I would appreciate any help you or others could offer.In my receivedDocumnet the value is “null”