Hi Patrick, Couldn't you just use WOLongResponse so that it keeps the first connection alive until it responds?
Regards, Rob. 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 protected]) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/rob%40synapticstorm.com > > This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
