Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] Performancemonitoring aspect

Well.. about what I expected really but, still i needed, to check if
there where something i have missed in the scoping of aspects.

My problem is that i have a "stateless asynchronous" system, where i
need to record a startpoint, and and endpoint not knowing how many
steps there are in between.

So i have a solution using alot of javacode in one aspect handling the
start of the message I receive (from a socketstream containing xml).
In this aspect i can use a percflow scope since my parser is called by
the io reader and when i have parsed my message to a xml object, i get
a unique handle (a message id in the xml document).
Then I add that handle to a static hashmap with a jamon monitor as the
value part.

So when it becomes that time of day to pass the message on to other
applications i have a new aspect that have a pointcut who figures out
what the end of the "flow" is, I then read the messageid from the
xmlobject i have, and look up the jamon monitor in the "starting"
aspect and stops it.

Well.. thats atleast what i have done, it works, but are not as
elegant as I wanted, I really would prefer having only one aspect for
this, but then i got problems with scoping.

But hey guys/girls what are you saying.. you cant read my mind ;)

regards
Kaare



On 03/02/06, Wes Isberg <wes@xxxxxxxxxxxxxx> wrote:
> 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
> >
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>


Back to the top