Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 183
  • Last Modified:

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!
1 Solution
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.


Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now