TCP/IP timeout on database application?

[DanielUK]

Not sure if this question is in the correct place.

We have a custom database app that fires up an XML inventory update file to our php driven shopping cart, the website processes the information and returns a 200 OK response to the database app.

This all works until the xml feed contains over 3000 product records and the database app times out waiting for a response - 20 minutes in this case, which is the database apps own timeout.

We've run tests to work out how long the shopping cart takes to process 3000 odd items and it's about 8 minutes and the shopping cart developers have worked out it is appearing to send a 200 OK response after this time, well within the database apps own timeout.

Interestingly if I post 2800 products, the cart processes them and sends a response within about 5 minutes. This tells me that something is going wrong just after this time.

The shopping cart developers are saying everything is OK as far as the cart is concerned as it is processing the 3000 odd products and returning a response. The database app developers are still looking at possible reasons as their timeout of 20 minutes should be more than enough to wait for a response that should happen about 8 minutes into the process.

However, I am wondering if there could be something else that might cause the two apps to stop talking with each other, so I'm here to see if it potentially could be a TCP/IP problem. The machine that is outputting the XML to the shopping cart is a Windows 2000 server if that makes a difference.

Any ideas?

Thanks

Dan

 

[North323]

increase your tcp timeout

 

[DanielUK]

Thanks, what is the default timeout (I'm presuming it's at least 5 minutes) and where do I change it? Just trying to be very sure it is this.

Thanks again

Dan

 

[North323]

the tcp timeout is in the application somewhere. usually called the config file. you'd have to ask your application support person

 

[DonMc67]

I think you are going to have to actually replicate your problem. You've proven the app will work for 8 minutes with your own eyes.

Is there a potential data mismatch in the update that hangs things up?

 

[kbing]

To solve this problem you will want to look at the TCPIP packets between the workstation and server that are involved with the application. How? Install WireShark on the workstation and start capturing traffic. Go thru the application and test it out until you replicate the problem. Note the time the problem occurs so you can go to the timestamped TCPIP packets in Wireshark.

Once you have this examing the conversation between the machines and you can determine if there are tcpip problems like re-transmissions, lost packets, etc...all of which can affect application performance and behaviors.