When the IS publish large document larger than 15M bytes,there are exceptions occured.And the documents are remained in the document store,so IS can not publish documents to Broker anymore.The exception message is:

2005-07-08 11:05:45 CST [ISS.0098.0064D] Publishing delayed while outbound store is draining. Service: wm.server.publish:publish
OutboundSimpleQueueDocReader.handleMessages(…) caught throwable com.wm.app.b2b.server.dispatcher.exceptions.EndpointUnavailableException: [ISS.0098.9014] BrokerException: Comm Failure (102-2051): Unable to send to Broker. Error ‘java.net.SocketException: Connection reset by peer: socket write error’ was reported bythe send call.

OutboundSimpleQueueDocReader.handleMessages(…) EndpointUnavailableException OutboundSimpleQueueDocReader calling nackMessage no of msgs=2 msgstore size=3 2005-07-08 11:10:07 CST [ISS.0098.0035V1] Regular-SimpleQueueDocReader detected Endpoint Unavailable. Going into a wait state.

I have set the size both of the document store and the trigger document store to 100M,and the Maximum Documents to Send per Transaction of the Outbound Document Store is set to 50.

The IS and Broker are both webMethods 6.1,the JVM is SUN 1.4.2.All the components are in Windows Advanced Server box with 2*2.8 CPUs and 4G RAM.

Thanks
kenny

check your broker queues and clear them. remove clients that are no longer created. If this doesn’t help create another broker and connect your IS to it and try publishing. Make sure that your broker server uses a larger data store.

Hi,
Adnan,thanks for your inputs.

Though webMethods has no method to clean Outbound Document Store,I can replace the Outbound Document Store to fix this issue indirectly.

But I still don’t know how to adjust IS and Broker to make IS can publish more larger than 30M bytes document to Broker.

Kenny,

Pushing very large docs through the Broker can create performance problems. In the past, I’ve seen production stability issues, although this may be better in more recent releases.

One alternative approach might be to write the large document to shared storage, or use FTP to move it, and use the Broker to signal that a new document is ready. The publishable document could contain info about the document location.

Regards

Hi,Mark
Thanks for your input,your idea is very good.Because the very large documents arrived occasionally,so I don’t want to program another solution for this inbound message.

So,in fact,I prefer publishing very large documents to Broker directly.But here,I don’t know how to adjust the IS and Broker to make IS can publish larger than 32M bytes documents to Broker.

I have modified storage-max-cache-size=256 and the qs_log_file is 128M.webMethods documents said,the size of document can be processed is equal to the size of qs_log_file.But in my case,I don’t know why it is disabled.

When the IS published documents exceed 35M,exception like "2005-07-08 11:05:45 CST [ISS.0098.0064D] Publishing delayed while outbound store is draining. Service: wm.server.publish:publish
OutboundSimpleQueueDocReader.handleMessages(…) caught throwable com.wm.app.b2b.server.dispatcher.exceptions.EndpointUnavailableException: [ISS.0098.9014] BrokerException: Comm Failure (102-2051): Unable to send to Broker. Error ‘java.net.SocketException: Connection reset by peer: socket write error’ was reported bythe send call.

OutboundSimpleQueueDocReader.handleMessages(…) EndpointUnavailableException OutboundSimpleQueueDocReader calling nackMessage no of msgs=2 msgstore size=3 2005-07-08 11:10:07 CST [ISS.0098.0035V1] Regular-SimpleQueueDocReader detected Endpoint Unavailable. Going into a wait state. " occured.

Kenny, while I certainly understand the desire to not rework the solution, you may want to seriously reconsider Mark’s advice. This topic has come up before on this forum and the advice is usually the same–don’t publish big documents to the broker. It’s not designed for that. Would advise that you follow Mark’s advise or if possible break up the document into smaller, independent parts.

If unable to do either, would advise contacting wM tech support for assistance.

I concur with above suggestions to redesign your integration, but in case you are constrained, disable guaranteed delivery on the document it should make things little faster for you but beware, if your integration fails or adapter looses subscription you will loose all transactional data. On the other hand it will be a good test to see if your broker is crapping out on guaranteed documents only or for every document size >15.

Hi,
Thank you very much!webMethods has fix to fix this issue.It is due to a bug about win32 API,BrokerCore_6-1_SP3_Fix6 can fix this issue.

Thanks!
Kenny