One WAY AOP invocation

[admin]

ho shit this was really me :)

I was just doing some maintenance on teh website and posted. sorry.

[hchirino]

> > /*
> > * letXDocletTakeit:one-way
> > */
> > public void doSomething() {}
> >
> > That is a good first pass. Below is a wish list
> of
> > additional features that if implemented by
> 'one-way'
> > invocations, would seriously reduce the need for
> > JMS.
> >
>
> Implement mother fucker :) I will make it worth your
> time, promise
>

Time is a resource i'm short on lately.

> > /*
> > * letXDocletTakeit:one-way timeout='100'
> > */
> > public void doSomething() {}
> >
> > Since the invocation is asynch, it does not
> execute
> > immeadiatly. We may want the invocation to abort
> if
> > we exceed a timeout.
>
> It is thread control. How relevant is it in an
> asynch mode? can you give me a JMS equivalent use
> case?
>

You are right. This stuff goes hand-in-hand with thread control. I like to think of it more as workload managment. The system could potetialy have thousands of one-ways that it needs to execute. You can't execute them all at the same time. The system needs to be smart about (by using one-way the metadata) which one-ways it will execute first.

Anyways... a JMS use case is an application the requests stock quotes. The request for the quote has to be satisfied within a given time or else the request becomes stale. Thus you put a time-to-live on the request so that the system can drop the request if it goes stale. No reason to have a system that is overworked process a stale request.

> > /*
> > * letXDocletTakeit:one-way priority='10'
> > */
> > public void doSomething() {}
> >
> > If we have many asynch invocations going through
> the
> > system we may want use priority to imlement QOS.
>
> pre-supposes a queue of invocations. check with Tom
> and Jeff on that requirement (I find it very valid).
>

Well, thats workload/thread managment. If our thread pool is not maxed out then, No there will be no queue. But if our thread pool is maxed out, the requests will need queue up.

Or we could have a one way with:
letXDocletTakeit:one-way exception-if-queued='true'
So that an exception gets thrown if the request would end up being queued. That way the caller could abort to avoid overworking the server.

> > /*
> > * letXDocletTakeit:one-way persistent='true'
> > */
> > public void doSomething() {}
> >
> > If this method gets called succesfully, the you
> > should be garanteed that the method call will get
> to
> > the object eventually. It should even survive a
> > server restart.
>
> ultra important. Does away with some of the benefits
> of "one-way" (you don't wait for serialization) but
> will be a massive one for banks. Serialization to
> disk in 1st iteration with requirement that all
> arguments be serializable.
>

Lets only make serializable a hard requirment if they NEED the 'persitent' feature. This coupled with TX managment would be very nice. This is how you can implement VERY LONG transactions that would take too long implement in a single unit of work. You use multiple units of work chained together with a asynch persient transacted method calls.

> Bill, this is in fact a STANDALONE aspect that the
> "invocation" object be persisted.
>

implementation detail.

> > /*
> > * letXDocletTakeit:one-way transacted='true'
> > */
> > public void doSomething() {}
> >
> > If the method that is calling doSomething() is in
> TX
> > x, then invocation to doSomething() should be
> delayed
> > until the TX x is commited.
>
> then change the name of it... it must be called
> "wait-for_commit=true
>

Anything that makes it easier to understand.

>
> > That's it.. I can't really think of any other JMS
> > features that can be applied to a Method
> invocation.
> >
>
> cool, go ahead :)
>

Well. this would be cool little project. The main support peices it would depenend are the AOP, Persistence, and Transaction subsystems. How close are we to doing easy POJO persistence?

Regards,
Hiram

[marc.fleury]

ho shit this was really me :)

I was just doing some maintenance on teh website and posted. sorry.

[bill.burke]

>
> Bill? when you are done trailblazing in cache land
> can you spend the 23 seconds it will take you to
> write this? Do we have an async invoker?

This is something we need the JBoss Remoting guys to write.

[marc.fleury]

OK I sent an email to jeff and tom... I can't believe we don't have an async invoker... once we have it it trivial to do the one way thingy... god I love it.

[jhaynie]

tom or i will implement asap

[hchirino]

/*
* letXDocletTakeit:one-way
*/
public void doSomething() {}

That is a good first pass. Below is a wish list of additional features that if implemented by 'one-way' invocations, would seriously reduce the need for JMS.

/*
* letXDocletTakeit:one-way timeout='100'
*/
public void doSomething() {}

Since the invocation is asynch, it does not execute immeadiatly. We may want the invocation to abort if we exceed a timeout.

/*
* letXDocletTakeit:one-way priority='10'
*/
public void doSomething() {}

If we have many asynch invocations going through the system we may want use priority to imlement QOS.

/*
* letXDocletTakeit:one-way persistent='true'
*/
public void doSomething() {}

If this method gets called succesfully, the you should be garanteed that the method call will get to the object eventually. It should even survive a server restart.

/*
* letXDocletTakeit:one-way transacted='true'
*/
public void doSomething() {}

If the method that is calling doSomething() is in TX x, then invocation to doSomething() should be delayed until the TX x is commited.

That's it.. I can't really think of any other JMS features that can be applied to a Method invocation.

Regards,
Hiram

[marc.fleury]

> /*
> * letXDocletTakeit:one-way
> */
> public void doSomething() {}
>
> That is a good first pass. Below is a wish list of
> additional features that if implemented by 'one-way'
> invocations, would seriously reduce the need for
> JMS.
>

Implement mother fucker :) I will make it worth your time, promise

> /*
> * letXDocletTakeit:one-way timeout='100'
> */
> public void doSomething() {}
>
> Since the invocation is asynch, it does not execute
> immeadiatly. We may want the invocation to abort if
> we exceed a timeout.

It is thread control. How relevant is it in an asynch mode? can you give me a JMS equivalent use case?

> /*
> * letXDocletTakeit:one-way priority='10'
> */
> public void doSomething() {}
>
> If we have many asynch invocations going through the
> system we may want use priority to imlement QOS.

pre-supposes a queue of invocations. check with Tom and Jeff on that requirement (I find it very valid).

> /*
> * letXDocletTakeit:one-way persistent='true'
> */
> public void doSomething() {}
>
> If this method gets called succesfully, the you
> should be garanteed that the method call will get to
> the object eventually. It should even survive a
> server restart.

ultra important. Does away with some of the benefits of "one-way" (you don't wait for serialization) but will be a massive one for banks. Serialization to disk in 1st iteration with requirement that all arguments be serializable.

Bill, this is in fact a STANDALONE aspect that the "invocation" object be persisted.

> /*
> * letXDocletTakeit:one-way transacted='true'
> */
> public void doSomething() {}
>
> If the method that is calling doSomething() is in TX
> x, then invocation to doSomething() should be delayed
> until the TX x is commited.

then change the name of it... it must be called "wait-for_commit=true


> That's it.. I can't really think of any other JMS
> features that can be applied to a Method invocation.
>

cool, go ahead :)

Bill needs help in the AOP holly :)
> Regards,
> Hiram
>
>

[marc.fleury]

hiram dear,


> You are right. This stuff goes hand-in-hand with
> thread control. I like to think of it more as
> workload managment. The system could potetialy have
> thousands of one-ways that it needs to execute. You
> can't execute them all at the same time. The system
> needs to be smart about (by using one-way the
> metadata) which one-ways it will execute first.

QOS on one-way will be a neat enhancement, raw power of no serialization will be the main benefit.

> Anyways... a JMS use case is an application the
> requests stock quotes. The request for the quote has
> to be satisfied within a given time or else the
> request becomes stale. Thus you put a time-to-live
> on the request so that the system can drop the
> request if it goes stale. No reason to have a system
> that is overworked process a stale request.

True. But the system issues like this one (overloaded box) are not really important in this case. I mean throw another box at the problem. Do you think a bank will drop a transaction because it can't throw a new JBoss at the problem? why do you think they are going with JBoss in the first place? so they can grow their trading volume for the cost of the hardware with free software.

The requirement is valid within a 'stale' mentality though, that you want a certain request to be executed within '2 seconds' to be valid or don't do it, it does depend on global clocks and this can be tough. I believe this is a tangantial requirement. Asynchronicity in and on itself is the first rate requirement for speed up and scalability.


> Well, thats workload/thread managment. If our

and again that's mostly bull.

> Or we could have a one way with:
> letXDocletTakeit:one-way exception-if-queued='true'
> So that an exception gets thrown if the request would
> end up being queued. That way the caller could abort
> to avoid overworking the server.

bla, throw another box...


> Lets only make serializable a hard requirment if they
> NEED the 'persitent' feature. This coupled with TX

YES



>
> > Bill, this is in fact a STANDALONE aspect that the
> > "invocation" object be persisted.
> >
>
> implementation detail.

I am saying that it is an aspect in and on itself. Meaning: imagine that our 'invokers', the ones from the JBoss remote framework show that aspect, that feature. You can say that "any" invocation be stored. whether you use EJB or JMS you are going through one of the invoker and persisting the invocation is a valid aspect. This one ships as a simple interceptor on the invoker. All invokers can have a persitent representation and we can swap in/out implementations as we get more fancy (i.e. we optimize serialization or use a small db on the client or a big db on the server with the server side aspect).



> Well. this would be cool little project. The main
> support peices it would depenend are the AOP,
> Persistence, and Transaction subsystems. How close
> are we to doing easy POJO persistence?

Pojo persistence is overkill here, we just need the serializable requirement as you pointed out. I don't even know that you need the transaction (except for the time out). In other words I think it can be implemented standalone and just add a line that does the serialization of the "invocation" to disk and that is your first iteration of the persistent AOP one-way,


marcf