Bermuda triangle coughs up requests hours later

I have a problem whereby a request is being sent from a browser and received by the server, which is good, but then the same request is being received by the server again anywhere between a few minutes and several hours later.

I have also had one case of a request being received 3 times. It only happens intermittently, maybe 1 in 3000 requests. I have client side javascript checking that the button is only pressed once and I have included a request parameter that shows what time the button was pressed in hours, minutes and milliseconds. This timestamp shows that the button was pressed only once for each duplicate request (or multiple times within the same millisecond).

The webserver is weblogic 5.1.

Beats me!
BugBlatterAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

BigRatCommented:
Normally a request is only sent after a connection has been made. The connection established port and IP address, A common problem is the way service providers just drop packets (as if they'd never seen them) (you use less resources dropping the packet than NAKing it) which causes other service providers to use alternate routes. Packets can literally hang around for hours.

One problem is socket reuse address. This stops socket resources in the protocol stack going into linger states waiting for proper closure. It does mean however that the port can get out-of-date packets presented to it if such have been circulating the system. Many TCP/IP stacks don't make a fuss about closing connections - by sending the relevant transport close packets - if they get an error on trying to close (because the SP has dropped the packet) they just ignore it and drop their socket. The effect is your server sits there with CLOSE or FIN_WAIT socket states. So if you have this on turn it off.

A common trick for critical database update is before starting the actual processing you throw out an HTML header (like your top of screen logo) and flush it out of the stack. If you get an I/O error on this operation you drop the remainder of the request.

Lastly you can avoid many problems regarding duplicate update if you use spinners. Each <FORM> has a hidden numeric field containing a database spinner. You need to keep a list of spinners processed but the advantage is that you execute the code only once. The alternative of using database primary keys (when numeric) suffers from  double possibly invalid update and also security problems.

HTH
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Web Servers

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.