Hi,

We are trying to send a file to a partner we have been sending to for a long time using a new receiver profile. If we try to send a file with a size of 3kb everything worls fine and we get an MDN back as it should do.

However if we try to send a file with bigger size (f.i. 461kb) we get the following error back:

Task 54ob2d00474i3u5t000000bc failed with no more retries available. Reason for failure - Delivery service for 54ob2d00474i3u5t000000bc failed with a status of fail and status message of com.wm.net.NetException: [ISC.0064.9324] Server Error: Service Unavailable [Task 54ob2d00474i3u5t000000bc failed with no more retries available. Reason for failure - Delivery service for 54ob2d00474i3u5t000000bc failed with a status of fail and status message of com.wm.net.NetException: [ISC.0064.9324] Server Error: Service Unavailable]

Partner receives files from other senders that are way larger (multiple megabytes) so that can not be the cause.

Anybody who has got any idea where this issue may reside?

Regards,
Martin

Have you tried setting TN Large Doc parameters in the config.cnf for the TN Package?
Im not sure if this will solve the issue but its worth a shot!

Any other thoughts experts?

Hi Scoobydoo,

Thanks for responding. To explain further, the document goes into Trading Networks correctly, then sending to partner starts. Partner can see the start of the connection but receives no further data or end of connection.

We get a http/1.1 503 back after 1-5 minutes after initiation of the process which finally gives the previous mentioned error, partner gets a http/1.1 500 error on his system one hour after starting the connection probably because of a time-out on this connection.

Any help or directions where to look to solve this issue?

Are you able to post similar sized file (~461kb) to a different partner system successfully?

What is the protocol used for communication with your partner system ( http/https )?

You mentioned new receiver profile, can you share what are the changes when compared to existing profile ( the one which worked fine ) ?

From the description i suspect the issue is with http method ( post vs get), if the method is set to ‘get’, than it limits the size of data that can be encoded in the url. Changing it to ‘post’ will resolve the issue.

Looks like you captured below mentioned error at default ( 4/info ) log level, increase the log level to 8 / trace to capture more information, which might be useful in troubleshooting the issue.

Yes, we are able to sent bigger files.

We are sending via http post. I have already set the loglevel to 10 but not much more information from that other then the errormessage and the http/1.1 503 message just before that.

I’m thinking it is a connection issue, I do not know a lot about that but could it be that if we are sending a 3kb-file we are only sending one packet over tcp\ip and if we send larger files it will be multiple packets?

Anyone has got more information regarding this packet-thing or any other direction where to look for the solution of this issue?

Involving network teams from both sides, might help you to nail/narrow down the issue source.

I see following interpretation for Http Error code 503 :

"The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the client SHOULD handle the response as it would for a 500 response.

I think IS is getting this error when trying to close the connectiong. Also how much time lapses when you invoke the http service and when you get the response ? Can you try sending 200K or 300K records and see what happens?

How are you sending the large data to your partner ? If its string can you try submitting in bytes or in stream and see what happens

Jiten

This indicates that the service on the machine that you reached is unavailable. A couple of possibilities exist:

1. The service is simply temporarily unavailable. Trying again should work, if service has been restored.

2. The service has been moved to another host. As you may know, the default behavior of the Sun JVM is to cache name resolution results forever. This means that once hostnameA resolves to an IP (e.g. 111.111.111.111) the JVM hosting IS will use that IP until a restart. If the IP of the hostname you’re trying to reach has changed for any reason, your IS will never reach it until it is restarted.

If this is the case (you’ll want to confirm with your partner) you can change the default behavior of the Sun JVM (assuming you’re using the Sun JVM) using a couple of Sun specific properties. These are described in an article on the Sun site.

Hi all,

Thanks for all the replies and suggestions, we think we have narrowed it down to a network related issue on partners environment. I will post a solution as soon as we have it, if someone else in the meantime has another suggestion where to look, please let me know.

Regards,
Martin

good to know.