You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Vincent Tence <vt...@sympatico.ca> on 2002/04/29 02:32:28 UTC
Instrument questions
I'm throwing in some more instrument questions:
1. Clients access the Instrumentables through InstrumentableDescriptors
via the InstrumentClient. In the DefaultInstrumentManager, shouldn't we
reset the optimized arrays m_instrumentableProxyArray and
m_instrumentableDescriptorArray when a new InstrumentableProxy is added
in registerInstrumentable() (like we do in configure())? That way we
could add Instrumentables - not declared in the config - after configuration,
which would be visible to clients.
What was your idea behind registering Instrumentables not declared in the config?
I'm not sure to understand this correctly.
2.To add new InstrumentSamples that have not been declared at configuration stage,
I would use the addXXXListeners() method on the InstrumentDescriptor in my client code
and pass it an InstrumentSample. But those samples would only be visible to my client
- as opposed to those added via addInstrumentSample() - correct?
(btw, is addInstrumentSample() in InstrumentProxy public on purpose?)
I may want to do that to let the administrator specify custom samples when the application is running.
Is that possible?
Thanks,
Vincent
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Instrument questions
Posted by Vincent Tence <Vi...@gemplus.com>.
Everything in both altrmi and instrument works fine.
After a quite long timeout, the altrmi code on the client returns
from setHostContext() and throws an Exception.
The problem is within the Tomcat classloader (4.0.1), which never returns
when it
loads the class which has dependencies on missing/wrong version of classes.
The AltrmiServer starts a SocketServer, which accepts a connection, then
instanciate
a SocketStreamServerConnection. This is when the pb occurs and the server
hangs.
The client sends an OpenConnectionRequest and never gets a reply.
Vincent
> -----Original Message-----
> From: Vinay Chandran [mailto:vinayc77@yahoo.com]
> Sent: Tuesday, April 30, 2002 4:24 PM
> To: Avalon Developers List
> Subject: RE: Instrument questions
>
>
> Vincent,
> Kewl ! .....
> So was the exception caught and not indicated
> promptly by altrmi or by instrumentation libraries?
>
> V i n a y.
>
> --- Vincent_Tence <Vi...@gemplus.com> wrote:
> > Leif,
> >
> > Damnit all my fault. I forgot to include one jar
> > used by the altrmi jar in
> > my webapp and Tomcat (I use 4.0.1) classloader
> > was hanging up when loading the
> > SocketStreamServerConnection class. That's
> > why the connection was accepted but the client
> > never got an answer to the OpenConnectionRequest.
> >
> > Now it seems to work fine. I'll carry on with the
> > instrumentation of my
> > framework.
> >
> > Thanks for your help guys,
> > Vincent
> >
> > > -----Original Message-----
> > > From: Vincent Tence
> > [mailto:Vincent.TENCE@gemplus.com]
> > > Sent: Tuesday, April 30, 2002 1:45 PM
> > > To: 'Avalon Developers List'
> > > Subject: RE: Instrument questions
> > >
> > >
> > > I looked at the status of the ports on my machine
> > to see that
> > > the server is
> > > properly started, the client can connect to the
> > > server but gets no response to the Altrmi
> > OpenConnectionRequest.
> > >
> > > Thx,
> > > Vincent
> > >
> > > > -----Original Message-----
> > > > From: Leif Mortenson
> > [mailto:leif@tanukisoftware.com]
> > > > Sent: Tuesday, April 30, 2002 12:11 PM
> > > > To: Avalon Developers List
> > > > Subject: Re: Instrument questions
> > > >
> > > >
> > > > Vincent Tence wrote:
> > > >
> > > > >Now the question is: why can't the client
> > connect to the server?
> > > > >
> > > > When you first open a connection to the
> > InstrumentManager.
> > > > You should
> > > > get an InstrumentManager dialog.
> > > > Is the title = "[Not Connected]
> > (localhost:15555)" or does it
> > > > give the
> > > > name of the server InstrumentManager?
> > > >
> > > > The client is designed to work when the server
> > is not running
> > > > and then
> > > > reconnect when the server comes
> > > > back on line. It would actually be nice to be
> > able to disable the
> > > > feature where altrmi tries to reconnect
> > > > 3 times. This would clean things up a bit.
> > > >
> > > > I could probably get rid of this appearant hang
> > problem by
> > > making the
> > > > menus be driven off of a cached
> > > > version of information from the host rather than
> > requesting
> > > live info
> > > > when the menus are being displayed.
> > > >
> > > > Like you said though, we still have to figure
> > out why you are
> > > > not able
> > > > to connect. Are you sure that the
> > > > port is correct?
> > > >
> > > > Cheers,
> > > > Leif
> > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > >
> > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > >
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - your guide to health and wellness
> http://health.yahoo.com
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Instrument questions
Posted by Vinay Chandran <vi...@yahoo.com>.
Vincent,
Kewl ! .....
So was the exception caught and not indicated
promptly by altrmi or by instrumentation libraries?
V i n a y.
--- Vincent_Tence <Vi...@gemplus.com> wrote:
> Leif,
>
> Damnit all my fault. I forgot to include one jar
> used by the altrmi jar in
> my webapp and Tomcat (I use 4.0.1) classloader
> was hanging up when loading the
> SocketStreamServerConnection class. That's
> why the connection was accepted but the client
> never got an answer to the OpenConnectionRequest.
>
> Now it seems to work fine. I'll carry on with the
> instrumentation of my
> framework.
>
> Thanks for your help guys,
> Vincent
>
> > -----Original Message-----
> > From: Vincent Tence
> [mailto:Vincent.TENCE@gemplus.com]
> > Sent: Tuesday, April 30, 2002 1:45 PM
> > To: 'Avalon Developers List'
> > Subject: RE: Instrument questions
> >
> >
> > I looked at the status of the ports on my machine
> to see that
> > the server is
> > properly started, the client can connect to the
> > server but gets no response to the Altrmi
> OpenConnectionRequest.
> >
> > Thx,
> > Vincent
> >
> > > -----Original Message-----
> > > From: Leif Mortenson
> [mailto:leif@tanukisoftware.com]
> > > Sent: Tuesday, April 30, 2002 12:11 PM
> > > To: Avalon Developers List
> > > Subject: Re: Instrument questions
> > >
> > >
> > > Vincent Tence wrote:
> > >
> > > >Now the question is: why can't the client
> connect to the server?
> > > >
> > > When you first open a connection to the
> InstrumentManager.
> > > You should
> > > get an InstrumentManager dialog.
> > > Is the title = "[Not Connected]
> (localhost:15555)" or does it
> > > give the
> > > name of the server InstrumentManager?
> > >
> > > The client is designed to work when the server
> is not running
> > > and then
> > > reconnect when the server comes
> > > back on line. It would actually be nice to be
> able to disable the
> > > feature where altrmi tries to reconnect
> > > 3 times. This would clean things up a bit.
> > >
> > > I could probably get rid of this appearant hang
> problem by
> > making the
> > > menus be driven off of a cached
> > > version of information from the host rather than
> requesting
> > live info
> > > when the menus are being displayed.
> > >
> > > Like you said though, we still have to figure
> out why you are
> > > not able
> > > to connect. Are you sure that the
> > > port is correct?
> > >
> > > Cheers,
> > > Leif
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > >
> <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Instrument questions
Posted by Vincent Tence <Vi...@gemplus.com>.
Leif,
Damnit all my fault. I forgot to include one jar used by the altrmi jar in
my webapp and Tomcat (I use 4.0.1) classloader
was hanging up when loading the SocketStreamServerConnection class. That's
why the connection was accepted but the client
never got an answer to the OpenConnectionRequest.
Now it seems to work fine. I'll carry on with the instrumentation of my
framework.
Thanks for your help guys,
Vincent
> -----Original Message-----
> From: Vincent Tence [mailto:Vincent.TENCE@gemplus.com]
> Sent: Tuesday, April 30, 2002 1:45 PM
> To: 'Avalon Developers List'
> Subject: RE: Instrument questions
>
>
> I looked at the status of the ports on my machine to see that
> the server is
> properly started, the client can connect to the
> server but gets no response to the Altrmi OpenConnectionRequest.
>
> Thx,
> Vincent
>
> > -----Original Message-----
> > From: Leif Mortenson [mailto:leif@tanukisoftware.com]
> > Sent: Tuesday, April 30, 2002 12:11 PM
> > To: Avalon Developers List
> > Subject: Re: Instrument questions
> >
> >
> > Vincent Tence wrote:
> >
> > >Now the question is: why can't the client connect to the server?
> > >
> > When you first open a connection to the InstrumentManager.
> > You should
> > get an InstrumentManager dialog.
> > Is the title = "[Not Connected] (localhost:15555)" or does it
> > give the
> > name of the server InstrumentManager?
> >
> > The client is designed to work when the server is not running
> > and then
> > reconnect when the server comes
> > back on line. It would actually be nice to be able to disable the
> > feature where altrmi tries to reconnect
> > 3 times. This would clean things up a bit.
> >
> > I could probably get rid of this appearant hang problem by
> making the
> > menus be driven off of a cached
> > version of information from the host rather than requesting
> live info
> > when the menus are being displayed.
> >
> > Like you said though, we still have to figure out why you are
> > not able
> > to connect. Are you sure that the
> > port is correct?
> >
> > Cheers,
> > Leif
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Instrument questions
Posted by Vincent Tence <Vi...@gemplus.com>.
I looked at the status of the ports on my machine to see that the server is
properly started, the client can connect to the
server but gets no response to the Altrmi OpenConnectionRequest.
Thx,
Vincent
> -----Original Message-----
> From: Leif Mortenson [mailto:leif@tanukisoftware.com]
> Sent: Tuesday, April 30, 2002 12:11 PM
> To: Avalon Developers List
> Subject: Re: Instrument questions
>
>
> Vincent Tence wrote:
>
> >Now the question is: why can't the client connect to the server?
> >
> When you first open a connection to the InstrumentManager.
> You should
> get an InstrumentManager dialog.
> Is the title = "[Not Connected] (localhost:15555)" or does it
> give the
> name of the server InstrumentManager?
>
> The client is designed to work when the server is not running
> and then
> reconnect when the server comes
> back on line. It would actually be nice to be able to disable the
> feature where altrmi tries to reconnect
> 3 times. This would clean things up a bit.
>
> I could probably get rid of this appearant hang problem by making the
> menus be driven off of a cached
> version of information from the host rather than requesting live info
> when the menus are being displayed.
>
> Like you said though, we still have to figure out why you are
> not able
> to connect. Are you sure that the
> port is correct?
>
> Cheers,
> Leif
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Instrument questions
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Vincent Tence wrote:
>Now the question is: why can't the client connect to the server?
>
When you first open a connection to the InstrumentManager. You should
get an InstrumentManager dialog.
Is the title = "[Not Connected] (localhost:15555)" or does it give the
name of the server InstrumentManager?
The client is designed to work when the server is not running and then
reconnect when the server comes
back on line. It would actually be nice to be able to disable the
feature where altrmi tries to reconnect
3 times. This would clean things up a bit.
I could probably get rid of this appearant hang problem by making the
menus be driven off of a cached
version of information from the host rather than requesting live info
when the menus are being displayed.
Like you said though, we still have to figure out why you are not able
to connect. Are you sure that the
port is correct?
Cheers,
Leif
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Instrument questions
Posted by Vincent Tence <Vi...@gemplus.com>.
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:leif@tanukisoftware.com]
> 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:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Instrument questions
Posted by Leif Mortenson <le...@tanukisoftware.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: RE:Instrument questions + Altrmi questions
Posted by Vincent Tence <vt...@sympatico.ca>.
Somehow the client tries to connect to the server, which is started, but
gets no response. And it gets stuck. I wonder if this has to do with
Tomcat or if I'm just missing something terribly obvious.
On Mon, 2002-04-29 at 21:26, Vincent Tence wrote:
> I've identified the problem. It seems that the main thread is waiting on a
> synchronized block because
> AltrmiFactory.setHostContext() does not return.
>
> Anybody can help on this?
>
> Thanks,
> Vincent
>
> > -----Original Message-----
> > From: Vincent Tence [mailto:Vincent.TENCE@gemplus.com]
> > Sent: Monday, April 29, 2002 4:40 PM
> > To: 'Avalon Developers List'
> > Subject: RE: Instrument questions
> >
> >
> > 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?
> >
> > Thx,
> > Vincent
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: RE:Instrument questions + Altrmi questions
Posted by Vinay Chandran <vi...@yahoo.com>.
Vincent,
My best guess is that the ClientClassAltrmiFactory
is not able to find the stubs and it throwing
exception which is not printed on the console .
(I feel the exception thus generated is not
printed on the console;
InstrumentManagerConnection.tryOpen() ...)
zzz!! ,
Vinay
--- Vincent Tence <vt...@sympatico.ca> wrote:
> Sure. I am using the instrument-client code. The
> server is the
> InstrumentManagerAltrmiServer from the
> instrument-manager package. My
> server is run from a webapp in Tomcat.
>
> Vincent
>
> On Tue, 2002-04-30 at 02:54, Vinay Chandran wrote:
> > Vincent,
> > Can you furnish more details about the client side
> > factory and hostcontext that you are using ..
> >
> > Thanx,
> > V i n a y
> > --- Vincent_Tence <Vi...@gemplus.com>
> wrote:
> > > I've identified the problem. It seems that the
> main
> > > thread is waiting on a
> > > synchronized block because
> > > AltrmiFactory.setHostContext() does not return.
> > >
> > > Anybody can help on this?
> > >
> > > Thanks,
> > > Vincent
> > >
> > > > -----Original Message-----
> > > > From: Vincent Tence
> > > [mailto:Vincent.TENCE@gemplus.com]
> > > > Sent: Monday, April 29, 2002 4:40 PM
> > > > To: 'Avalon Developers List'
> > > > Subject: RE: Instrument questions
> > > >
> > > >
> > > > 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?
> > > >
> > > > Thx,
> > > > Vincent
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > >
> <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > >
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > >
> <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Health - your guide to health and wellness
> > http://health.yahoo.com
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: RE:Instrument questions + Altrmi questions
Posted by Vincent Tence <vt...@sympatico.ca>.
Sure. I am using the instrument-client code. The server is the
InstrumentManagerAltrmiServer from the instrument-manager package. My
server is run from a webapp in Tomcat.
Vincent
On Tue, 2002-04-30 at 02:54, Vinay Chandran wrote:
> Vincent,
> Can you furnish more details about the client side
> factory and hostcontext that you are using ..
>
> Thanx,
> V i n a y
> --- Vincent_Tence <Vi...@gemplus.com> wrote:
> > I've identified the problem. It seems that the main
> > thread is waiting on a
> > synchronized block because
> > AltrmiFactory.setHostContext() does not return.
> >
> > Anybody can help on this?
> >
> > Thanks,
> > Vincent
> >
> > > -----Original Message-----
> > > From: Vincent Tence
> > [mailto:Vincent.TENCE@gemplus.com]
> > > Sent: Monday, April 29, 2002 4:40 PM
> > > To: 'Avalon Developers List'
> > > Subject: RE: Instrument questions
> > >
> > >
> > > 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?
> > >
> > > Thx,
> > > Vincent
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - your guide to health and wellness
> http://health.yahoo.com
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE:Instrument questions + Altrmi questions
Posted by Vinay Chandran <vi...@yahoo.com>.
Vincent,
Can you furnish more details about the client side
factory and hostcontext that you are using ..
Thanx,
V i n a y
--- Vincent_Tence <Vi...@gemplus.com> wrote:
> I've identified the problem. It seems that the main
> thread is waiting on a
> synchronized block because
> AltrmiFactory.setHostContext() does not return.
>
> Anybody can help on this?
>
> Thanks,
> Vincent
>
> > -----Original Message-----
> > From: Vincent Tence
> [mailto:Vincent.TENCE@gemplus.com]
> > Sent: Monday, April 29, 2002 4:40 PM
> > To: 'Avalon Developers List'
> > Subject: RE: Instrument questions
> >
> >
> > 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?
> >
> > Thx,
> > Vincent
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE:Instrument questions + Altrmi questions
Posted by Vincent Tence <Vi...@gemplus.com>.
I've identified the problem. It seems that the main thread is waiting on a
synchronized block because
AltrmiFactory.setHostContext() does not return.
Anybody can help on this?
Thanks,
Vincent
> -----Original Message-----
> From: Vincent Tence [mailto:Vincent.TENCE@gemplus.com]
> Sent: Monday, April 29, 2002 4:40 PM
> To: 'Avalon Developers List'
> Subject: RE: Instrument questions
>
>
> 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?
>
> Thx,
> Vincent
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Instrument questions
Posted by Vincent Tence <Vi...@gemplus.com>.
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?
Thx,
Vincent
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Instrument questions
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Vincent Tence wrote:
>>I am currently reviewing the use of the listeners. Especially making
>>them available to remote clients. The
>>problem is that the listener methods are fired in the thread
>>where the
>>data are taken. If the listeners are
>>remote then this can severely affect the performance of the
>>application.
>>Thoughts on this?
>>
>>I was thinking about making a set of base descriptor interfaces which
>>could be accessed remotely as
>>well as a set which are more for in JVM use by tools which would make
>>the listener methods available.
>>
>>
>
>Is it possible that the descriptors accessed by remote clients spawn threads
>in which they notify listeners? That's just a thought, since I rarely do
>remote
>stuff. I have to take a look at altrmi to see how this works.
>
There are two problems that I see here.
1) The extra threads are in themselves quite a resource drain.
Especially on Linux where each thread
is a process with all the overhead that goes along with it. I could
work around this by having a pool
of threads whose job it was to service listeners. But see #2
2) Whenever data is passed between threads, you need to have a way to do
this. This would have to
involve creating event objects (which means added garbage collection)
You would also have to have
a queue to hold the events waiting to be processed by the listener
threads. This queue would have
to be synchronized. Not sure if you noticed, but I was able to get rid
of almost all synchronization
in the processing of data (except for the samples).
I keep coming back to this though, so ...
>>Also, any ideas for making the client more user friendly. I was
>>planning to add a tree like you had
>>made for the altprofile client. The tree would be located in
>>the window
>>opened for each remote
>>InstrumentManager. This was the user could get away from the menu
>>driven interface.
>>
>>
>
>That would be nice indeed.
>
Once the underlying data gets finalized, this should go fairly quickly.
>>I was also considering adding child instrumentables to the
>>descriptors.
>> This way they would mirror
>>structure of the actual instrumentables. Currently, the child
>>instrumentables are only used for naming
>>the instruments which are all viewed as being direct
>>instruments of the
>>root instrumentable. Not
>>only is this confusing, but I have found that it can cause
>>problems in
>>large applications as the total
>>number of instruments can grow quite large.
>>This can be done without changing the instrument project in
>>any way. so
>>no user code should be
>>affected. The instrument.xml files would require some slight
>>modifications though.
>>
>>Finally, I am also planning to put the ability to save
>>Instrument Sample
>>snapshots to a state file
>>back in. This was being done in the altprofile code. I have been
>>waiting until things settle down
>>a bit though. The ability to save and load the desktop of the client
>>will also be put back in.
>>
>>
>
>Could you explain a little be further what you have in mind?
>
On the server side (instrument-manager), the sample data can be very
useful even across JVM
invocations. The idea is to save the contents of all the samples,
including onces added via
leases, at a regular interval. When the JVM is restarted, the data will
be loaded so that there
will be only a small gap in the data when the JVM was down. This worked
great in the altprofile
stuff when used with the Wrapper (see phoenix) to restart the JVM after
a crash. You can then
see what led to the crash.
On the client side, I often found myself using the same "desktop" of
windows when working
on a given problem. This would let you save a set of charts for say
debugging JDBC connections.
One for general server health. You could then load these saved desktops
again later to quickly
see the data that you are interrested in. It basicly saves you time
going through and recreating the
same set of charts each time you reopen the client. (This was working
in the altprofile stuff).
Leif
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Instrument questions
Posted by Vincent Tence <Vi...@gemplus.com>.
Thanks for the detailed answers.
See answers inline
-- Vincent
> -----Original Message-----
> From: Leif Mortenson [mailto:leif@tanukisoftware.com]
> Sent: Monday, April 29, 2002 1:19 PM
> To: Avalon Developers List
> Subject: Re: Instrument questions
>
>
> Vincent Tence wrote:
>
> >Looking at the javadoc of InstrumentSample, it suggests that we could
> >add InstrumentSamples to an Instrument as a result of a
> request from an
> >InstrumentClient. Does that mean we should add
> addInstrumentSample() and
> >removeInstrumentSample() to InstrumentDescriptor interface?
> >
> I have been working out the issues with how to add samples at
> run time.
> I am currently working on
> a system where a client will request that a sample be added given a
> lease time. The client must then
> renew this lease or the sample will be destroyed by the
> InstrumentManager after the lease expires.
>
> The benefits of this method are that the client does not have
> to worry
> about cleaning up its samples
> in the event of an abnormal shutdown.
>
> It also makes the case where multiple clients are using the
> same sample
> easier. Each client requests
> a lease and the InstrumentManager makes sure that the sample stays
> around until the later of the leases
> expires.
>
> Using leases also makes it possible for a client to request that a
> sample be registered to record data
> event when the client is not connected. The client could request a
> lease time of 24 hours before going
> home at night. Completely disconnect from the server. Then
> reconnect
> the next morning and see the
> results of the data that had been collected durring the night.
>
> Currently this is about 75% impemented. samples are created,
> but they
> do not yet expire. You can try
> it out using the instrument-client in CVS.
>
> Samples are requested by a client using the createInstrumentSample()
> method of the InstrumentDescriptor.
> The addInstrumentSample() method in the InstrumentProxy class
> should now
> be private. Samples can
> only be removed by the InstrumentManager when their lease
> expires, so a
> removeInstrumentSample
> method is not needed.
>
> Samples which are defined in the configuration file will
> never expire.
> They are to be thought of as
> resources that a client can always depend on.
>
> Do you think I am going in the right direction here?
Sure.
I like your idea of the lease time. I was thinking yesterday that clients
should be able to add samples at run time, but then I did not want the
manager
to expose too much to the clients for its own integrity. The lease time
looks like a
good compromise.
>
> >>1. Clients access the Instrumentables through
> InstrumentableDescriptors
> >>via the InstrumentClient. In the DefaultInstrumentManager,
> shouldn't we
> >>reset the optimized arrays m_instrumentableProxyArray and
> >>m_instrumentableDescriptorArray when a new
> InstrumentableProxy is added
> >>in registerInstrumentable() (like we do in configure())? That way we
> >>could add Instrumentables - not declared in the config -
> after configuration,
> >>which would be visible to clients
> >>
> This was not intentional. Good catch. It should be fixed
> now in CVS. :-)
Cool.
>
> >>What was your idea behind registering Instrumentables not
> declared in the config?
> >>I'm not sure to understand this correctly.
> >>
> The InstrumentManager is actually designed to be completely
> independent.
> You should be able
> to register any Instrumentable at any time in the life of an
> application. The Instrumentables defines
> in the configuration are only necessary when things like
> names or static
> samples need to be declared.
I'm glad to hear that.
That's what I thought seeing all the nice synchronization code you put in.
>
> >>2.To add new InstrumentSamples that have not been declared
> at configuration stage,
> >>I would use the addXXXListeners() method on the
> InstrumentDescriptor in my client code
> >>and pass it an InstrumentSample. But those samples would
> only be visible to my client
> >>- as opposed to those added via addInstrumentSample() - correct?
> >>(btw, is addInstrumentSample() in InstrumentProxy public on
> purpose?)
> >>I may want to do that to let the administrator specify
> custom samples when the application is running.
> >>Is that possible?
> >>
> See above. Did I answer these questions.
Nicely. It all makes sense.
>
> I am currently reviewing the use of the listeners. Especially making
> them available to remote clients. The
> problem is that the listener methods are fired in the thread
> where the
> data are taken. If the listeners are
> remote then this can severely affect the performance of the
> application.
> Thoughts on this?
>
> I was thinking about making a set of base descriptor interfaces which
> could be accessed remotely as
> well as a set which are more for in JVM use by tools which would make
> the listener methods available.
Is it possible that the descriptors accessed by remote clients spawn threads
in which they notify listeners? That's just a thought, since I rarely do
remote
stuff. I have to take a look at altrmi to see how this works.
>
> For the samples, it is possible for the client to request
> snapshots or
> call any of the descriptor's methods
> at their leasure without affecting the performance of the
> application.
> This can be done without listeners.
>
> Keep the questions coming.
>
> Also, any ideas for making the client more user friendly. I was
> planning to add a tree like you had
> made for the altprofile client. The tree would be located in
> the window
> opened for each remote
> InstrumentManager. This was the user could get away from the menu
> driven interface.
That would be nice indeed.
>
> I was also considering adding child instrumentables to the
> descriptors.
> This way they would mirror
> structure of the actual instrumentables. Currently, the child
> instrumentables are only used for naming
> the instruments which are all viewed as being direct
> instruments of the
> root instrumentable. Not
> only is this confusing, but I have found that it can cause
> problems in
> large applications as the total
> number of instruments can grow quite large.
> This can be done without changing the instrument project in
> any way. so
> no user code should be
> affected. The instrument.xml files would require some slight
> modifications though.
>
> Finally, I am also planning to put the ability to save
> Instrument Sample
> snapshots to a state file
> back in. This was being done in the altprofile code. I have been
> waiting until things settle down
> a bit though. The ability to save and load the desktop of the client
> will also be put back in.
Could you explain a little be further what you have in mind?
>
> Cheers,
> Leif
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Instrument questions
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Vincent Tence wrote:
>Looking at the javadoc of InstrumentSample, it suggests that we could
>add InstrumentSamples to an Instrument as a result of a request from an
>InstrumentClient. Does that mean we should add addInstrumentSample() and
>removeInstrumentSample() to InstrumentDescriptor interface?
>
I have been working out the issues with how to add samples at run time.
I am currently working on
a system where a client will request that a sample be added given a
lease time. The client must then
renew this lease or the sample will be destroyed by the
InstrumentManager after the lease expires.
The benefits of this method are that the client does not have to worry
about cleaning up its samples
in the event of an abnormal shutdown.
It also makes the case where multiple clients are using the same sample
easier. Each client requests
a lease and the InstrumentManager makes sure that the sample stays
around until the later of the leases
expires.
Using leases also makes it possible for a client to request that a
sample be registered to record data
event when the client is not connected. The client could request a
lease time of 24 hours before going
home at night. Completely disconnect from the server. Then reconnect
the next morning and see the
results of the data that had been collected durring the night.
Currently this is about 75% impemented. samples are created, but they
do not yet expire. You can try
it out using the instrument-client in CVS.
Samples are requested by a client using the createInstrumentSample()
method of the InstrumentDescriptor.
The addInstrumentSample() method in the InstrumentProxy class should now
be private. Samples can
only be removed by the InstrumentManager when their lease expires, so a
removeInstrumentSample
method is not needed.
Samples which are defined in the configuration file will never expire.
They are to be thought of as
resources that a client can always depend on.
Do you think I am going in the right direction here?
>>1. Clients access the Instrumentables through InstrumentableDescriptors
>>via the InstrumentClient. In the DefaultInstrumentManager, shouldn't we
>>reset the optimized arrays m_instrumentableProxyArray and
>>m_instrumentableDescriptorArray when a new InstrumentableProxy is added
>>in registerInstrumentable() (like we do in configure())? That way we
>>could add Instrumentables - not declared in the config - after configuration,
>>which would be visible to clients
>>
This was not intentional. Good catch. It should be fixed now in CVS. :-)
>>What was your idea behind registering Instrumentables not declared in the config?
>>I'm not sure to understand this correctly.
>>
The InstrumentManager is actually designed to be completely independent.
You should be able
to register any Instrumentable at any time in the life of an
application. The Instrumentables defines
in the configuration are only necessary when things like names or static
samples need to be declared.
>>2.To add new InstrumentSamples that have not been declared at configuration stage,
>>I would use the addXXXListeners() method on the InstrumentDescriptor in my client code
>>and pass it an InstrumentSample. But those samples would only be visible to my client
>>- as opposed to those added via addInstrumentSample() - correct?
>>(btw, is addInstrumentSample() in InstrumentProxy public on purpose?)
>>I may want to do that to let the administrator specify custom samples when the application is running.
>>Is that possible?
>>
See above. Did I answer these questions.
I am currently reviewing the use of the listeners. Especially making
them available to remote clients. The
problem is that the listener methods are fired in the thread where the
data are taken. If the listeners are
remote then this can severely affect the performance of the application.
Thoughts on this?
I was thinking about making a set of base descriptor interfaces which
could be accessed remotely as
well as a set which are more for in JVM use by tools which would make
the listener methods available.
For the samples, it is possible for the client to request snapshots or
call any of the descriptor's methods
at their leasure without affecting the performance of the application.
This can be done without listeners.
Keep the questions coming.
Also, any ideas for making the client more user friendly. I was
planning to add a tree like you had
made for the altprofile client. The tree would be located in the window
opened for each remote
InstrumentManager. This was the user could get away from the menu
driven interface.
I was also considering adding child instrumentables to the descriptors.
This way they would mirror
structure of the actual instrumentables. Currently, the child
instrumentables are only used for naming
the instruments which are all viewed as being direct instruments of the
root instrumentable. Not
only is this confusing, but I have found that it can cause problems in
large applications as the total
number of instruments can grow quite large.
This can be done without changing the instrument project in any way. so
no user code should be
affected. The instrument.xml files would require some slight
modifications though.
Finally, I am also planning to put the ability to save Instrument Sample
snapshots to a state file
back in. This was being done in the altprofile code. I have been
waiting until things settle down
a bit though. The ability to save and load the desktop of the client
will also be put back in.
Cheers,
Leif
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Instrument questions
Posted by Vincent Tence <vt...@sympatico.ca>.
Looking at the javadoc of InstrumentSample, it suggests that we could
add InstrumentSamples to an Instrument as a result of a request from an
InstrumentClient. Does that mean we should add addInstrumentSample() and
removeInstrumentSample() to InstrumentDescriptor interface?
Thanks,
Vincent
On Mon, 2002-04-29 at 00:32, Vincent Tence wrote:
> I'm throwing in some more instrument questions:
>
> 1. Clients access the Instrumentables through InstrumentableDescriptors
> via the InstrumentClient. In the DefaultInstrumentManager, shouldn't we
> reset the optimized arrays m_instrumentableProxyArray and
> m_instrumentableDescriptorArray when a new InstrumentableProxy is added
> in registerInstrumentable() (like we do in configure())? That way we
> could add Instrumentables - not declared in the config - after configuration,
> which would be visible to clients.
> What was your idea behind registering Instrumentables not declared in the config?
> I'm not sure to understand this correctly.
>
> 2.To add new InstrumentSamples that have not been declared at configuration stage,
> I would use the addXXXListeners() method on the InstrumentDescriptor in my client code
> and pass it an InstrumentSample. But those samples would only be visible to my client
> - as opposed to those added via addInstrumentSample() - correct?
> (btw, is addInstrumentSample() in InstrumentProxy public on purpose?)
> I may want to do that to let the administrator specify custom samples when the application is running.
> Is that possible?
>
> Thanks,
> Vincent
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>