Here is the stack trace of interest:
"InstrumentClientFrameRunner" prio=5 tid=0x89dd9c8 nid=0xc0 runnable
[0x8f2f000..0x8f2fdc4]
at java.net.SocketInputStream.socketRead(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:86)
at java.net.SocketInputStream.read(SocketInputStream.java:102)
at java.io.DataInputStream.readInt(DataInputStream.java:338)
at
org.apache.excalibur.altrmi.client.impl.stream.ClientCustomStreamReadWriter.
readReply(ClientCustomStreamReadWriter.java:84)
at
org.apache.excalibur.altrmi.client.impl.stream.ClientCustomStreamReadWriter.
postRequest(ClientCustomStreamReadWriter.java:66)
at
org.apache.excalibur.altrmi.client.impl.stream.StreamInvocationHandler.handl
eInvocation(StreamInvocationHandler.java:140)
at
org.apache.excalibur.altrmi.client.impl.AbstractAltrmiFactory.setHostContext
(AbstractAltrmiFactory.java:93)
at
org.apache.avalon.excalibur.instrument.client.InstrumentManagerConnection.op
en(InstrumentManagerConnection.java:96)
at
org.apache.avalon.excalibur.instrument.client.InstrumentManagerConnection.tr
yOpen(InstrumentManagerConnection.java:128)
at
org.apache.avalon.excalibur.instrument.client.InstrumentClientFrame.run(Inst
rumentClientFrame.java:102)
at java.lang.Thread.run(Thread.java:484)
I thought the client code was not returning from
AltrmiFactory.setHostContext(), but after waiting long enough
the client returns:
AltRMI service abnormally ended, Trying to reconnect (attempt 0)
AltRMI service abnormally ended, Trying to reconnect (attempt 1)
AltRMI service abnormally ended, Trying to reconnect (attempt 2)
Unexpected error caught in ProfilerFrame runner:
org.apache.excalibur.altrmi.common.AltrmiInvocationException: Too many
retries on abended service
at
org.apache.excalibur.altrmi.client.impl.DefaultConnectionListener.serviceAbe
nd(DefaultConnectionListener.java:94)
at
org.apache.excalibur.altrmi.client.impl.stream.StreamInvocationHandler.handl
eInvocation(StreamInvocationHandler.java:182)
at
org.apache.excalibur.altrmi.client.impl.AbstractAltrmiFactory.setHostContext
(AbstractAltrmiFactory.java:93)
at
org.apache.avalon.excalibur.instrument.client.InstrumentManagerConnection.op
en(InstrumentManagerConnection.java:96)
at
org.apache.avalon.excalibur.instrument.client.InstrumentManagerConnection.tr
yOpen(InstrumentManagerConnection.java:128)
at
org.apache.avalon.excalibur.instrument.client.InstrumentClientFrame.run(Inst
rumentClientFrame.java:102)
at java.lang.Thread.run(Thread.java:484)
Now the question is: why can't the client connect to the server?
Thanks,
Vincent
> -----Original Message-----
> From: Leif Mortenson [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, April 30, 2002 2:58 AM
> To: Avalon Developers List
> Subject: Re: Instrument questions
>
>
> Vincent Tence wrote:
>
> >Leif,
> >
> >I'm facing a problem with the InstrumentManager running
> under Tomcat. I have
> >a simple yet powerful
> >MVC2 framework designed to integrate with Avalon nicely and
> I want to add
> >instrumentation to it.
> >
> >I configured the framework to use the
> InstrumentComponentManager and I added
> >a few Instruments to the
> >Front Component to record things like number of requests received,
> >successful, request latency, ...
> >
> >The problem occurs when I connect the client to the altrmi
> server. The
> >connection seems to go fine,
> >but I when I try to access the menu InstrumentManagers, my
> client hang up.
> >I tried to remove all my instrumentables to run the manager
> with only the
> >ComponentManager and itself as instrumentables,
> >but it still hang up.
> >
> >Any idea?
> >
> When the Instrument Managers menu is first selected, the menu
> has to be
> rebuilt. I am
> assuming that you are not seeing this menu and that you have already
> opened a connection
> to your Tomcat app.
> The only thing in that rebuild menu code that could be
> causing problems
> is the call to
> InstrumentClientFrame.getInstrumentManagerConnections() This will
> return the cached
> array of InstrumentManagers to avoid synchronization. But if
> the array
> does not yet exist
> then it must be created in updateInstrumentManagerConnectionArray()
> This requires a
> lock on the InstrumentClientFrame instance. (Could you add
> some print
> statements in there
> to confirm that this is where things are hanging up:
> ---
> private InstrumentManagerConnection[]
> updateInstrumentManagerConnectionArray()
> {
>
> System.out.println("updateInstrumentManagerConnectionArray() 1");
> synchronized (this)
> {
>
> System.out.println("updateInstrumentManagerConnectionArray()
> 2");
> ...
> }
> }
> ---
>
> Most likely this is the problem. Problem is who has that lock.
>
> To track down problems like this. Java has this neat little
> dump stack
> trace feature
> that has saved me lots of time since I found out about it.
>
> From the console, press CTRL-BREAK on Windows or CRTL-\ on
> Linux. You
> should get a
> lot of data dumped out to the console describing what each
> thread in the
> system is doing as well
> as a list of semaphores towards the end.
>
> Could you please send me this output.
>
> Thanks,
> Leif
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
