Trying async in 1.1 -- behaves like sync

[rdewell]

Thought I'd give this a shot. We have a process that can occur in the background instead of holding up the display of the next page. Perfect candidate for async.

So I created a stateless test bean to call during another form submission / action:

@Stateless
@Name("OrderProcessor")
@Interceptors(SeamInterceptor.class)
public class OrderProcessorImpl implements OrderProcessor, Serializable{
 private static final long serialVersionUID = -8591335166721681758L;

 @Asynchronous
 public void process(@Duration long initialStartMS, String id) {
 LOG.info("Processing: " + id);

 try {
 Thread.currentThread().sleep(1000 * 30);
 } catch (InterruptedException e) {
 e.printStackTrace();
 }
 }

The 30 second sleep in there just simulates some long running logic in the method.

I expected to:

- Have the submitted action that calls this async method to return almost immediately with a view.
- In 60 seconds (which is what I pass in the duration param), see the "Processing: XYZ" in the logs.
- Of course have the currently submitted action be unaffected by either the 60 seconds passed in as the init duration, and definitely not affected by the 30 second sleep..

But instead:

- Almost immediately after submitting the form action I see in the logs: "Processing: xyz"..
- A full 30 seconds goes by before my view returns from the action that was called (the action which called the async).

?

[gavin.king]

You need to put the annotations on the local interface (OrderProcessor).

[rdewell]

Thanks -- that and:

<component name="org.jboss.seam.core.dispatcher"
 class="org.jboss.seam.core.Dispatcher" />

did the trick.

Also, a suggested addition. I really don't need for the calling method to care about the duration or interval. I'd love to be able to leave that up to the method that defines Asynchronous.. like @Asynchronous(duration=234234).

Ryan

[gavin.king]

That is really easy to implement, but do you think it ever makes sense to hardcode a duration? (And, also, is there a good way to specify a literal date in an annotation?)


Well, I guess I could come up with some kind of expression language for expiry/duration, eg:

@Asynchronous(duration="1 day", intervalDuration="2 weeks")

@Asynchronous(expiry="1 hour + 10 ms", intervalDuration="1000 ms")

Or, perhaps:

@Asynchronous(expiry="#{event.expiry}", intervalDuration="#{event.repeat}")

(1) What is the real usecase?
(2) Which works best for you?
(3) Do you think you really need it?
(4) Do you want to implement it and submit a patch (its straightforward, I promise.)

(Yes, I missed the declaration when I wrote the docs. Bad on me.)

[rdewell]

I forsee our app using @Asynchronous as an orthogonal concern of the caller. The caller (in the cases I imagine in our app) really has no reason to know what the frequency, duration, etc of that async method is. It just needs to say "do this", and then carry along. Maybe this would be comparable to a JMS message use case.

As for how it would work -- I'd be happy with simple long values on the annotation. I can hard code those as static longs for abstraction.

I wish I had extra time to submit a patch. Working against some deadlines here. I guess consider this just a "would be nice to have" that I thought of while using @Asynchronous.

Ryan