Re: Failed to contact xxxx-1085, ellpack

At 16:30 04/10/2005, Chuck Hill wrote:


>On Oct 4, 2005, at 1:30 AM, John Pollard wrote:
>
>>
>>When we were running on Panther Server, we had this type of problem
>>prior to WO5.2.3 which seemed to fix it. But since we have moved to
>>Tiger (Client), JavaMonitor has seemed temperamental and these
>>CLOSE_WAIT problems are cropping up again. Does anyone know if
>>Apple have this back on their bug list again? I am not convinced
>>that any of my app instances are going south, other than being cut
>>off by wotaskd.
>Is the JVM version the same?  Is wotaskd running as the same user on
>both machines?

I run wotaskd as root on both machines.

java -version on the current Tiger Client deployed box gives me:

java version "1.4.2_07"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_07-215)
Java HotSpot(TM) Client VM (build 1.4.2-50, mixed mode)

Unfortunately the previous Panther XServe box is unavailable to me at present.

wotaskd runs as root on the current deployment box, I think the same on the 
previous XServe. I chose root because I had a problem with no workaround I 
could find, to do with generating reports and accessing graphics resources



>>I will look at some of the debugging techniques that Chuck suggests.
>>
>>I do use the wo services restart technique that Nick advised of,
>>though that will cut off any active sessions I believe.
>I don't think so.  The connection between user and instance/session
>is maintained in the URL/cookies sent with each request. The requests
>being processed are done with wotaskd and will respond directly to
>the woadaptor.

Absolutely correct, I was fooled by the fact that while wotaskd is 
restarting, any sessions will not get the response they would like. But 
when it is back, the session is indeed maintained which makes sense.

I have not got a more thorough workaround if CLOSE_WAIT processes start 
building up, so I am not desperate.