I have a custom adapter and the JDBC adapter. I’m doing a publish-wait from the custom to the JDBC adapter but frequently I get a ‘request timed out’ error. For both adapters I’ve set the # of adapter processes to 2. Both adapters are in the same client group and I’ve verified that canSubscribe and canPublish is set for the request and reply documents.
My timeout is set for 300 seconds but it’s only taking .084 seconds for the JDBC adapter to execute it’s stored proc. I added steps to output documents so I can analyze if the stored procedure is indeed exceeding the 300 seconds. It’s working fine! Load on the database is low.
Over the weekend the integrations worked fine, they were called about 20 times.
I also have another publish-wait that has had no problems, the only difference being that the two adapters are in separate client groups.
Why you get time-out is because you are using multiple sessions of the adapter who sends “outboundCall”: PublishandWaitforReply. The wM support cannot explain this. They (when they were in ActiveWorks) indicated that when you set the number of adapter sessions higher than ONE and use PublishandWaitforReply, the behavior of the adapter will be strange. If you use multiple sessions, sometimes one of the sessions will have time-out. I think there are too many queued documents (events) on the same adapter. The reply document for one of the sessions cannot reach the session and this session gets time-out. The similar happened: when you configure two adapters on different computers. The adapters are connected to the same broker, have the same name and the shared-status, and are in the same client group. Each adapter has only one session. If you use PublishandWaitforReply. One of the adapter can get time-out.
Can someone here give their experiences and more explanations?
I can’t explain it, but I have seem similar behavior.
I once used an adapter for which there was only one component and for which there were 20 threads available. The component made heavy use of Publish-And-Wait. The business problem required one process to be run in parallel 20 times every 60 seconds. (I only present that information for the curious – you can ignore it as irrelevant, really.)
The Adapter successfully builds 20 clients at startup. I verified this by using the Manager tool. However, the Enterprise Broker did not recognize that all 20 threads were available – at first. When the integration was “started”, only one of the 20 threads would receive documents from the Broker. The one thread would process a document and then receive another from the Broker and then another until all 20 documents had been processed.
With each minute, though, a few other threads would be “activated”. I don’t understand it, but at the next 60 second marker, three of the 20 threads would process data from the Broker. In the next minute, the number of active clients would be seven. And so on until all 20 were “live”.
Like I said, I am not sure why this happened, but the Publish-And-Wait would time out frequently until all 20 threads were working as expected.
This is more a anecdote than an answer. Hope I didn’t bore you.
2, 10, 20, 100 processes/threads doesn’t mean that there are that number of broker clients with subscriptions to the request event.
When you have an adapter with multiple threads, each thread creates a connection to the broker. These connections do not create subscriptions for any of your events (there are subscriptions for some housekeeping events only). The main thread/connection gets ALL of the events and dispatches them to waiting threads. What the dispatch model is, I don’t know. Clearly though it can create situations where publishers time-out waiting for the muti-threaded adapter to respond. Bump up the time-out of the requestor, if possible, for your integration.
You can confirm the subscription behavior by using manager to look at the subscriptions for each of the clients. You’ll see that the main thread does all kinds of event retrieves and little or no publishes/delivers. The “child” connections don’t have many event retrieves but do all the publishing/deliveries.
The broker connection that each client has is for the thread to do its own publish/deliver activity. This way the threads don’t interfere with each other if they do things like request/reply operations.
I’ve seen this behavior with the ATC and the standard DB adapter. With the standard ILA too.
If I have some of this wrong, or if it doesn’t jive with the behavior you’ve seen, please post it.
Q: Why you get time-out is because you are using multiple sessions of the adapter who sends “outboundCall”: PublishandWaitforReply. The wM support cannot explain this.
A: Yes, they can. For version 4.1.1 there have been 4 service packs that partly fixed the problem. So please apply the latest platform patches available. The number of adaptersessions has nothing to do with it.
Old school adapters (recognizable in their .cfg) have no troubles, because they simply don’t use it. I advice you to use deliverRequestAndWait (also part of broker client).
Enjoy,
FKATSD Shyam
~Formal Known As Technical Support Dude~
Following your advise, I install the latest platform patch (BrokerCore_4-1-1_SP16_WIN) and test again. The time-out is still there.
I use two adapters, one is Vantive adapter and another one is Oracle DB adapter. Within the EI component on Vantive adapter, I use “Publish Document and Wait for Reply” to publsih a ducument to the DB adapter and wait for a reply. When I use only ONE Vantive adapter session and send 100 trigger documents to the Vantive component, there are not any time-out errors from Vantive component which sends also 100 “Publish Document and Wait for Reply” documents. However, when I increase the number of Vantive adapter sessions to 2 and send another 100, I get 50 time-out errors due to “Publish Document and Wait for Reply” from Vantive adapter. This indicates that using multiple adapter sessions creates the time-out. However we don’t the reason.
Moreover, there is not a deliverRequestandWait function on the EI.
Could you indicate which 411 service pack fixed this problem?
Multiple adapter sessions… It could be because of the maximum publish request and wait time (which is about 12 minutes), I’ll browse through the patches and post my conclusions here.