[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-users] Performancemonitoring aspect
|
It sounds like you have the aspect part right in terms of
using advice to pick out the join points. Otherwise, you need
to decide how the calls are associated (e.g., from the same
thread) and how to correlate them (e.g., with a Timer in a
ThreadLocal or a percflow aspect, or by generating a log for
start/stop calls with the name of the originating thread and
post-processing the log, etc.) I think that's straight Java,
and depends mostly on your program which people on the list
can't really guess.
Wes
> ------------Original Message------------
> From: Kaare Nilsen <kaare.nilsen@xxxxxxxxx>
> To: aspectj-users@xxxxxxxxxxx
> Date: Fri, Feb-3-2006 3:47 AM
> Subject: Re: [aspectj-users] Performancemonitoring aspect
>
> Well..
> The problem here would be that this Apsect as coded below would be a
> singletong, therefore i woul end up having each call to
> updateCustomer() changing the start timestamp, and each call to the
> dao change the end.
> So i would en up that the starttime would be the start of the last
> executed updateCustomerCall(), and the end time be the last finished
> dao call and that may not be the dao update for the updateCustomer()
> call who owns the starttime.
>
> So.
> I would need to add a static hashmap or something of the timer handle
> (am going to use jamon btw) so that i on the dao call could do a
> map.get().stop(), but then again what would the key for that map be..
> lets say both the methodscalls have no params, and i cannot get the
> customer id or things like that.
>
> On 03/02/06, Conway. Fintan (IT Solutions) <Fintan.Conway@xxxxxx>
> wrote:
> > How about :
> >
> > @Aspect
> > MyAspect{
> > private long start;
> > private long end;
> > private long duration;
> >
> > @Before("call (* Customer.updateCustomer(..)"
> > public startTimer(){
> > start = System.getCurrentTimeMillis();
> > }
> >
> > @After("call (* CustomerDao.save(..)"
> > public stopTimer(){
> > end = System.getCurrentTimeMillis();
> > duration = end - start;
> > log("Time to save Customer : " + duration);
> > }
> > }
> >
> > HTH,
> >
> > Fintan
> >
> > -----Original Message-----
> > From: aspectj-users-bounces@xxxxxxxxxxx
> > [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Kaare Nilsen
> > Sent: 03 February 2006 10:49
> > To: aspectj-users@xxxxxxxxxxx
> > Subject: [aspectj-users] Performancemonitoring aspect
> >
> >
> > Hi.
> >
> > i was just wandering if there could be a clever way of making an
> aspect
> > that could figure out the duration in time from a call in one class
> to a
> > later call in another class ?
> >
> > To elaborate a little.
> > Let say we have a class called Customer who has a method,
> > updateCustomer() And then we have a class CustomerDao with a method
> > save() In addition we have a unspecified number of logical
> application
> > layers, doing alot of things as a part of this process, some of them
> > e.g. checking the given adress on a central adress register and so
> on.
> >
> > So what i would like to is to start a timer when someone calls
> > updateCustomer(), then let the applicationflow go about it's ususal
> > tasks, some of them asynchroniously and some not, until we get to the
> > point that the dao is finished with the persisting in the database,
> then
> > i would like to stop the timer handle and log the result. Ideas
> anyone ?
> >
> > @Aspect
> > MyAspect{
> > private Timer timer = new Timer();
> >
> > @Before("call (* Customer.updateCustomer(..)"
> > public startTimer(){
> > timer.start();
> > }
> >
> > @After("call (* CustomerDao.save(..)"
> > public stopTimer(){
> > timer.stop();
> > timer.log();
> > }
> > }
> >
> >
> > Best regards
> > Kaare Nilsen
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
> >
> > * ** *** ** * ** *** ** * ** *** ** *
> > This email and any files transmitted with it are confidential and
> > intended solely for the use of the individual or entity to whom they
> > are addressed.
> > Any views or opinions presented are solely those of the author, and
> do not necessarily
> > represent those of ESB.
> > If you have received this email in error please notify the sender.
> >
> > Although ESB scans e-mail and attachments for viruses, it does not
> guarantee
> > that either are virus-free and accepts no liability for any damage
> sustained
> > as a result of viruses.
> >
> > * ** *** ** * ** *** ** * ** *** ** *
> >
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
