On 09/23/2010 03:46 PM, James Shipton wrote:
> Hi Aurelien
>
> We have 32 instances running, load balanced across 2 application servers.
>
> I have looked at the application logs - and the only evidence of the broken
> request in the logs is when a new instance:88 is switched to and no session
> is found
>
> 21/09 11:00:35 INFO [WorkerThread9] reg.Application
> (handleSessionRestorationErrorInContext:210) -
> handleSessionRestorationErrorInContext for session
>
> The original broken request doesn't appear to get as far as instance:99
>
>
> On a broken request we see
>
>> Info: Sending request to instance number 99, port 5555
>> Info: Trying to contact Example:99 on (5555)
>> Info: Example:99 on (5555) connected [pooled: Yes]
>> Info: Request POST
>> /WebObjects/Example.woa/99/wo/45ZaOYm9bb40enplQDqAPM/8.7 HTTP/1.1
>> sent, awaiting response
>
>
> So the adaptor thinks it has found instance :99 "Info: Example:99 on (5555)
> connected [pooled: Yes]"
>
> But on a successful request we see some extra steps to confirm connection
> before a request is made
>
>> Info: Sending request to instance number 99, port 5555
>> Info: Trying to contact Example:99 on (5555)
> **** Info: attempting to connect to example.com on port 5555
> **** Info: Created new pooled connection [1] to example.com:5555
> **** Info: Using pooled connection to example.com:5555
>> Info: Example:99 on (2013) connected [pooled: Yes]
>> Info: Request POST
>> /WebObjects/Example.woa/99/wo/45ZaOYm9bb40enplQDqAPM/2.7 HTTP/1.1
>> sent, awaiting response
>
>
> Why are these extra steps not logged on a broken request. Why is no
> connection attempted?
There is no connection attempted cause it's already an available connection
(not locked).
if you look at _runRequest() in transaction.c, you would see it tries to reuse
an existing connexion or recreate a new
by calling tr_open() from transport.c :
-> if non locked connexion (c) is exist and is not NULL it return it after
after "locking" the instance handle and
_runRequest() in "connected [pooled: Yes]" is loged
-> if there is no connexion available in the connexion poll (or the connexion
pool is empty) it create a new connexion
(block after c == NULL test )
that's why you have in the log "Created new pooled connection..." and "Using
pooled connection to ..."
(the code that makes the connexion is launched from transport->openinst, a
function pointer to openapp in nbsocket.c
if you have a look in openapp for the TCP socket creation you can find that if
there is a problem with it it would log
an error)
As there is no broken pipe in the logs instance 99 doesn't seems to do the
request/response loop, it may have a deadlook.
For investigation when the adaptor found an instance dead you can check if it
is really the case or do any other test
(like command like jstack over ssh... ) with something like :
tail -f /tmp/WebObjects.log | grep --line-buffered -B 1 dead | head -n 1 |
awk -F ' *[() ] *' '{ print $6":"$7 }' |
xargs wget
Aurélien
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-deploy mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-deploy/archive%40mail-archive.com
This email sent to [email protected]
