4 Replies Latest reply on Oct 31, 2006 11:26 AM by rdewell

    Trying async in 1.1 -- behaves like sync


      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:

      public class OrderProcessorImpl implements OrderProcessor, Serializable{
       private static final long serialVersionUID = -8591335166721681758L;
       public void process(@Duration long initialStartMS, String id) {
       LOG.info("Processing: " + id);
       try {
       Thread.currentThread().sleep(1000 * 30);
       } catch (InterruptedException e) {

      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).


        • 1. Re: Trying async in 1.1 -- behaves like sync

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

          • 2. Re: Trying async in 1.1 -- behaves like sync

            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).


            • 3. Re: Trying async in 1.1 -- behaves like sync

              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.)

              • 4. Re: Trying async in 1.1 -- behaves like sync

                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.