Re: x-webobjects-request-id lacking uniqueness?
Re: x-webobjects-request-id lacking uniqueness?
- Subject: Re: x-webobjects-request-id lacking uniqueness?
- From: Patrick Middleton <email@hidden>
- Date: Tue, 7 Dec 2010 11:30:13 +0000
On 6 Dec 2010, at 23:15, Ralf Schuchardt wrote:
Patrick Middleton schrieb:
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.
It sounds as if you are dropping the first 16 chars when comparing
the unique IDs? This would be a bad idea, as there can be more
httpds at the same time, each with his own counter.
I'd guess that either the shared memory or
the locking isn't working as expected.
The adapter code is using standard pthreads calls for locking and
it seems not doing anything wrong.
What I am doing is reporting a bug in the WebObjects API adaptor,
with
the circumstances as how how I encountered it. It might be
possible to
deduce, for example, that the application list etc (see config.c
in the
Adaptors project) is in shared memory, while uniqueID_counter (see
transaction.c) is not in shared memory, but should be, if we cared.
Putting the uniqueID_counter into shared memory seems unnecessary,
it should be protected by process id and process start time (as
long as you are using only one webserver).
Are you really seeing _complete_ unique ids reused?
Yes. I should point out that I am using Apache 1.3.41, with
singlethreading, forking of the master instance, and so on, so "as
long as you are using only one webserver" is up for discussion.
I suggest the first 16 chars are being reused because they get set in
the master instance of httpd (the one that runs as root) when it
starts, then copied/inherited in forked instances of httpd (the ones
running as www), and since the value of uniqueID_str is not NULL it
is not reset.
The last 8 are then being reused ... sometimes used once, sometimes
twice, the most I remember seeing is five times ... because when a
forked instance is created, a value is already set. The master
instance of httpd maintains a pool of httpd instances to handle
requests and the value of uniqueID_counter returned is a function of
what it was when the parent httpd was forked.
I am attaching my test project; I built and installed, and I
configured four instances, and there is a test script. I doubt my
test project will be much use, but those of you building on newer
systems with Apache 2.2 should be able to establish if this is still
a problem.
Having thought about this some more:
[1] moving uniqueID_counter into shared memory would work, and x-
webobjects-request-id values would be allocated in an ascending
sequence, but there would be a performance penalty from additional
locking.
[2] it is not clear what, if anything, relies on x-webobjects-request-
id being set correctly or even being present
[3] adequate uniqueness could instead be created by ensuring that
when httpd forks, the child process resets uniqueID_str.
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.
Attachment:
RequestID.zip
Description: Zip archive
-- Patrick
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