On 6 Dec 2010, at 13:09, Patrick Middleton wrote:
> 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
_______________________________________________
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