You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Marcus Crafter <cr...@fztig938.bank.dresdner.net> on 2002/03/22 17:02:28 UTC
Intrumentation classes
Hi Leif!
Hope things are going well mate.
What's the current status on the profiling/instrumenting code ?
How is it all going ? Our discussions finished up a few weeks
back with the excalibur rearrangements, what was left to discuss ?
(I think we were talking about history managers, and dynamically
modifying sample intervals via the gui tool ?).
While the rearrangements have been going on I've done some work on
the gui tool with jtree's and jtable's, etc.
Looking forward to helping out where ever I can.
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Intrumentation classes
Posted by Paul Hammant <Pa...@yahoo.com>.
Leif,
>>
>> I am going to have to play with this tomorrow ;)
>
>
>
> Be aware that there is currently a memory leak in the altrmi
> communication between the
> client and the manager JVMs. I am talking to Paul about it.
> Hopefully we will get it
> fixed soon. The instrument and instrument-manager projects should not
> have any leaks
> as long as a client is not connected to them.
It is a definate leak. I have written a test in AltRMI that models it.
In need to do some weak reference stuff to fix it.
The alternative is to use more immutable beans (AKA value objects) and
less pass-by-value interfaces. Each one of those while in use should
mean an open reference linkage from the cleint to the server. Of course
the bug is that all are kept open, when only those that are in use
should be.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Intrumentation classes
Posted by Leif Mortenson <le...@silveregg.co.jp>.
Peter Donald wrote:
> On Tue, 26 Mar 2002 23:27, Leif Mortenson wrote:
>
>>Sorry for the long delay. Work has been busy <:-}
>>
>>I spent some time this weekend and got the basics of the instrument package
>>working. Things have been divided into 3 sub projects to make the
>>interdependencies between sub projects work correctly.
>>
>
> Woohoo!
>
> I am going to have to play with this tomorrow ;)
Be aware that there is currently a memory leak in the altrmi communication between the
client and the manager JVMs. I am talking to Paul about it. Hopefully we will get it
fixed soon. The instrument and instrument-manager projects should not have any leaks
as long as a client is not connected to them.
Cheers,
Leif
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Intrumentation classes
Posted by Leif Mortenson <le...@silveregg.co.jp>.
Peter Donald wrote:
> On Tue, 26 Mar 2002 23:27, Leif Mortenson wrote:
>
>>Sorry for the long delay. Work has been busy <:-}
>>
>>I spent some time this weekend and got the basics of the instrument package
>>working. Things have been divided into 3 sub projects to make the
>>interdependencies between sub projects work correctly.
>>
>
> Woohoo!
>
> I am going to have to play with this tomorrow ;)
Looks like the memory leak is fixed. Paul was able to point me at the problem.
It was caused by a known bug in the Sun ObjectStream code. I am using the
CustomStream code that paul wrote instead. So far, it seems to have solved the
problem.
Cheers,
Leif
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Intrumentation classes
Posted by Peter Donald <pe...@apache.org>.
On Tue, 26 Mar 2002 23:27, Leif Mortenson wrote:
> Sorry for the long delay. Work has been busy <:-}
>
> I spent some time this weekend and got the basics of the instrument package
> working. Things have been divided into 3 sub projects to make the
> interdependencies between sub projects work correctly.
Woohoo!
I am going to have to play with this tomorrow ;)
--
Cheers,
Pete
*------------------------------------------------*
| You can't wake a person who is pretending |
| to be asleep. -Navajo Proverb. |
*------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Intrumentation classes
Posted by Paul Hammant <Pa...@yahoo.com>.
Jeff,
Sorry! I should have kept on top of the implications of the rename...
- Paul
>On Wed, Mar 27, 2002 at 06:56:34PM +0900, Leif Mortenson wrote:
>
>>Right now you have to define the properties declared in the
>>ant.properties.sample files. That appears to be how all the other
>>required jars are being referenced. How should this be done now? In
>>the all directory, there is the lib directory, but it does not make
>>sense to have copies of the jars in each sub-project which needs them.
>>
>
>ant.properties.sample seems fine for now.
>
>Btw, when I point it at altrmi built from CVS, it complains that the
>AltrmiInterfaceTask class doesn't exist. I think the following patch is
>needed:
>
>61c61
>< classname="org.apache.commons.altrmi.generator.ant.AltrmiInterfaceTask">
>---
>
>> classname="org.apache.commons.altrmi.generator.ant.AltrmiProxyTask">
>>
>
>
>Also, when I try to build instrument/, it fails:
>
>test-reports:
>
>BUILD FAILED
>
>/home/jeff/apache/jakarta/jakarta-avalon-excalibur/instrument/build.xml:153: Errors while applying transformations
>
>That's because there's no JUnit tests yet, so no TESTS-*.xml file generated, so
>the XSLT engine complains. Probably it's best to just comment out the junit and
>junitreport targets' contents until there's some tests.
>
>
>--Jeff
>
>
>--
>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: Intrumentation classes
Posted by Jeff Turner <je...@socialchange.net.au>.
On Wed, Mar 27, 2002 at 06:56:34PM +0900, Leif Mortenson wrote:
> Right now you have to define the properties declared in the
> ant.properties.sample files. That appears to be how all the other
> required jars are being referenced. How should this be done now? In
> the all directory, there is the lib directory, but it does not make
> sense to have copies of the jars in each sub-project which needs them.
ant.properties.sample seems fine for now.
Btw, when I point it at altrmi built from CVS, it complains that the
AltrmiInterfaceTask class doesn't exist. I think the following patch is
needed:
61c61
< classname="org.apache.commons.altrmi.generator.ant.AltrmiInterfaceTask">
---
> classname="org.apache.commons.altrmi.generator.ant.AltrmiProxyTask">
Also, when I try to build instrument/, it fails:
test-reports:
BUILD FAILED
/home/jeff/apache/jakarta/jakarta-avalon-excalibur/instrument/build.xml:153: Errors while applying transformations
That's because there's no JUnit tests yet, so no TESTS-*.xml file generated, so
the XSLT engine complains. Probably it's best to just comment out the junit and
junitreport targets' contents until there's some tests.
--Jeff
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Intrumentation classes
Posted by Leif Mortenson <le...@silveregg.co.jp>.
Right now you have to define the properties declared in the ant.properties.sample
files. That appears to be how all the other required jars are being referenced.
How should this be done now? In the all directory, there is the lib directory, but
it does not make sense to have copies of the jars in each sub-project which needs
them.
Leif
Paul Hammant wrote:
> Leif,
>
> Dude, I have checked in some updated altrmi jars to commons.
>
> Where are the equivlent jars in the excalibur CVS?
>
> How do I launch a test that illustrates the problem#
>
> Cheers,
>
> - Paul
>
>> Sorry for the long delay. Work has been busy <:-}
>>
>> I spent some time this weekend and got the basics of the instrument
>> package
>> working. Things have been divided into 3 sub projects to make the
>> interdependencies between sub projects work correctly.
>>
>> The first is the "instrument" sub project. This project contains all
>> of the classes that most classes need to make themselves fully
>> instrumentable.
>> this package has no dependencies so it is quite flexible.
>>
>> The second is the "instrument-manager" sub project. This project
>> contains
>> the InstrumentManager classes which actually collect data and do all
>> of the
>> profiling. It also contains an InstrumentComponentManager(ICM)
>> implementation
>> which works the same as the old ProfilerComponentManager.
>> This project is not yet 100% complete. I still have to get state
>> saving/loading
>> working again. And also implement dynamic InstrumentSamples. Soon.
>>
>> The third is the "instrument-client" sub project. This project
>> implements the
>> remote client GUI which can be used to connect to one or more remote
>> InstrumentManagers. The parts that are implemented are working, but
>> it still
>> needs some more work.
>> Currently, you can connect to multiple remote IMs and view pre configured
>> InstrumentSample data. (But it only works for localhost right now.)
>>
>> To try things out.
>> Run the examples in both the instrument-manager and instrument-client
>> sub projects.
>> Things work much as they did in the altprofile package.
>>
>> Known problems:
>> Currently, altrmi is kicking out some stack traces when the server is
>> killed. The
>> client will correctly reconnect, but you have to bear with the stack
>> traces for
>> now. Paul is working on fixing this. :-)
>>
>> I'll give a more thorough overview once things are nailed down a bit
>> more.
>>
>> Marcus, thanks for all your posts on the altprofile code. I am
>> working on getting
>> them all integrated.
>>
>> Cheers,
>> Leif
>>
>> Marcus Crafter wrote:
>>
>>> Hi Leif!
>>>
>>> Hope things are going well mate.
>>>
>>> What's the current status on the profiling/instrumenting code ?
>>> How is it all going ? Our discussions finished up a few weeks
>>> back with the excalibur rearrangements, what was left to discuss ?
>>>
>>> (I think we were talking about history managers, and dynamically
>>> modifying sample intervals via the gui tool ?).
>>> While the rearrangements have been going on I've done some
>>> work on
>>> the gui tool with jtree's and jtable's, etc.
>>> Looking forward to helping out where ever I can.
>>>
>>> Cheers,
>>>
>>> Marcus
>>>
>>>
>>
>>
>>
>> --
>> 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: Intrumentation classes
Posted by Paul Hammant <Pa...@yahoo.com>.
Leif,
Dude, I have checked in some updated altrmi jars to commons.
Where are the equivlent jars in the excalibur CVS?
How do I launch a test that illustrates the problem#
Cheers,
- Paul
> Sorry for the long delay. Work has been busy <:-}
>
> I spent some time this weekend and got the basics of the instrument
> package
> working. Things have been divided into 3 sub projects to make the
> interdependencies between sub projects work correctly.
>
> The first is the "instrument" sub project. This project contains all
> of the classes that most classes need to make themselves fully
> instrumentable.
> this package has no dependencies so it is quite flexible.
>
> The second is the "instrument-manager" sub project. This project
> contains
> the InstrumentManager classes which actually collect data and do all
> of the
> profiling. It also contains an InstrumentComponentManager(ICM)
> implementation
> which works the same as the old ProfilerComponentManager.
> This project is not yet 100% complete. I still have to get state
> saving/loading
> working again. And also implement dynamic InstrumentSamples. Soon.
>
> The third is the "instrument-client" sub project. This project
> implements the
> remote client GUI which can be used to connect to one or more remote
> InstrumentManagers. The parts that are implemented are working, but
> it still
> needs some more work.
> Currently, you can connect to multiple remote IMs and view pre configured
> InstrumentSample data. (But it only works for localhost right now.)
>
> To try things out.
> Run the examples in both the instrument-manager and instrument-client
> sub projects.
> Things work much as they did in the altprofile package.
>
> Known problems:
> Currently, altrmi is kicking out some stack traces when the server is
> killed. The
> client will correctly reconnect, but you have to bear with the stack
> traces for
> now. Paul is working on fixing this. :-)
>
> I'll give a more thorough overview once things are nailed down a bit
> more.
>
> Marcus, thanks for all your posts on the altprofile code. I am
> working on getting
> them all integrated.
>
> Cheers,
> Leif
>
> Marcus Crafter wrote:
>
>> Hi Leif!
>>
>> Hope things are going well mate.
>>
>> What's the current status on the profiling/instrumenting code ?
>> How is it all going ? Our discussions finished up a few weeks
>> back with the excalibur rearrangements, what was left to discuss ?
>>
>> (I think we were talking about history managers, and dynamically
>> modifying sample intervals via the gui tool ?).
>>
>> While the rearrangements have been going on I've done some work on
>> the gui tool with jtree's and jtable's, etc.
>>
>> Looking forward to helping out where ever I can.
>>
>> Cheers,
>>
>> Marcus
>>
>>
>
>
>
> --
> 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: Intrumentation classes
Posted by Leif Mortenson <le...@silveregg.co.jp>.
Sorry for the long delay. Work has been busy <:-}
I spent some time this weekend and got the basics of the instrument package
working. Things have been divided into 3 sub projects to make the
interdependencies between sub projects work correctly.
The first is the "instrument" sub project. This project contains all
of the classes that most classes need to make themselves fully instrumentable.
this package has no dependencies so it is quite flexible.
The second is the "instrument-manager" sub project. This project contains
the InstrumentManager classes which actually collect data and do all of the
profiling. It also contains an InstrumentComponentManager(ICM) implementation
which works the same as the old ProfilerComponentManager.
This project is not yet 100% complete. I still have to get state saving/loading
working again. And also implement dynamic InstrumentSamples. Soon.
The third is the "instrument-client" sub project. This project implements the
remote client GUI which can be used to connect to one or more remote
InstrumentManagers. The parts that are implemented are working, but it still
needs some more work.
Currently, you can connect to multiple remote IMs and view pre configured
InstrumentSample data. (But it only works for localhost right now.)
To try things out.
Run the examples in both the instrument-manager and instrument-client sub projects.
Things work much as they did in the altprofile package.
Known problems:
Currently, altrmi is kicking out some stack traces when the server is killed. The
client will correctly reconnect, but you have to bear with the stack traces for
now. Paul is working on fixing this. :-)
I'll give a more thorough overview once things are nailed down a bit more.
Marcus, thanks for all your posts on the altprofile code. I am working on getting
them all integrated.
Cheers,
Leif
Marcus Crafter wrote:
> Hi Leif!
>
> Hope things are going well mate.
>
> What's the current status on the profiling/instrumenting code ?
> How is it all going ? Our discussions finished up a few weeks
> back with the excalibur rearrangements, what was left to discuss ?
>
> (I think we were talking about history managers, and dynamically
> modifying sample intervals via the gui tool ?).
>
> While the rearrangements have been going on I've done some work on
> the gui tool with jtree's and jtable's, etc.
>
> Looking forward to helping out where ever I can.
>
> Cheers,
>
> Marcus
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>