x-webobjects-request-id lacking uniqueness?
x-webobjects-request-id lacking uniqueness?
- Subject: x-webobjects-request-id lacking uniqueness?
- From: Patrick Middleton <email@hidden>
- Date: Mon, 6 Dec 2010 13:09:44 +0000
I have an app doing something superficially like web services which
is sessionless and accessed via DirectActions. Because of other
activity in the database sometimes, database i/o can block for
several minutes. When this happens the Apache WebObjects adaptor's
loadbalancing features come into play, and redirect the request it
sent to an apparently unresponsive instance to a different instance,
which may in turn block on database i/o. The caller's browser waits
several minutes and then receives an "no instance available" page.
When the other activity in the database clears an, if the request
caused a database update, that update can be applied multiple times
because of each instance attempting to process the request. If the
first update changes the database in a way that prevents the other
updates from succeeding, they might report "update failed", and if
the database i/o hold up was only a few minutes, that page can be
returned to the caller -- a page saying that the update failed, when
in fact the update succeeded but the caller won't get to see that page.
What I thought about doing, and have largely done, is announce and
listen for activity via multicast datagrams. If an instance receives
a request via a direct action and I don't want it to be redirected
via the load balancer, enough information is broadcast such that
other instances waiting for requests will be able to tell that
another instance should already be processing it, and then generate a
response (without blocking on database i/o) to the effect that
database congestion may be in progress, that their request is being
processed, any database updates may or may not be committed but will
be committed at most once.
But what constitutes "enough information"? The WebObjects adaptor
adds a header "x-webobjects-request-id" (aka REQUEST_ID_HEADER, in
config.h) to a received request before writing it to an instance
(this header is not "leaked back" to the client) and this appears to
be unique: 24 chars long corresponding to three hexstrings of 32-bit
numbers, being the time at which some initialization code was called
in the process (httpd), the process identifier (of httpd), and a
unique sequence counter defended by a lock. The point at which this
header is added means that a redirected request will have the same x-
webobjects-request-id header.
And so to the subject line of this message: "x-webobjects-request-id
lacking uniqueness?" Of those 24 chars, the first 16 are effectively
fixed whenever httpd starts, and I appear to be seeing values being
reused for the last 8. I'd guess that either the shared memory or
the locking isn't working as expected.
Anybody else seeing this?
---
Regards Patrick
OneStep Solutions (Research) LLP
www.onestep.co.uk
This email, including any attachments, is confidential and intended solely for the person or organisation to whom it is addressed. If you are not the intended recipient you must not disseminate, distribute or copy any part of this email nor take any action in reliance on it.
If you have received this in error please notify the sender immediately by email or phone +44 (0)1702 426400 and delete this email and any attachments from your system.
Email transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of email transmission. If verification is required please request a hard-copy version.
OneStep Solutions LLP is registered in England and Wales under registration number OC337173 and has its registered office at 457 Southchurch Road, Southend-on-Sea, Essex SS1 2PH.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden