1 2 3 4 Previous Next 52 Replies Latest reply: Apr 1, 2008 2:09 PM by Carlo de Wolf Go to original post RSS
  • 30. Re: Quartz, timer unification, message inflow RAR
    Weston M. Price Master

    Right I agree, I think it makes the most sense to integrate Quartz straightaway. In fact, I believe this was always the intent at least as far as implementation was concerned.


    I would like to ask for a timer manager which isn't dependant on JMX (for the embedded stack).


    Yeah, I went back and forth on this one. The idea is that the version that exists in connector today is JMX dependent, however, in the jca project (not currently on HEAD) I have added timer annotations, and was planning on adding a TimerManager that was embeddable, or at the very least, didn't require JBossAS to run. I am finishing up touches on this and will check this in as soon as I can.

    I agree with the spi integration.

    I really appreciate you looking at this so quickly. Thanks!


  • 31. Re: Quartz, timer unification, message inflow RAR
    Scott Stark Master

    Some feedback.

    1. Is the TimerPropertyKey key needed as a wrapper? Currently it does not even properly wrap its Object key, and even if it did provide an equals/hashCode it would seem to be an unnecessary wrapper around the real key.

    2. Being able to access the TimerData from the Timer interface in the listener callback seems like something we need to support. In the case of both ejb and jmx timers there is a user data notion that can be passed in when the timer is created and retrieved from the timer callback object.

    3. What is the usecase for the distinct TimerListener, CancelTimerListener, and StopTimerListener? Wouldn't these be better combined into a single interface with either all three callbacks, or a single callback with a state enum?

    4. In terms of the most general timer scheduling method on the TimerManager, the method taking the TimerExcecutionContext would seem to be the place for extended scheduling semantics. Currently it has a period and data notion. I'm thinking we need more of a timer calendar notion to deal with non-trivial timer scheduling ala cron.

  • 32. Re: Quartz, timer unification, message inflow RAR
    Weston M. Price Master

    All good suggestions. I will incorporate. Again, this was a 'rough' draft just to get people talking about this stuff.

    Thanks.

  • 33. Re: Quartz, timer unification, message inflow RAR
    Weston M. Price Master

    Further, I agree with



    3. What is the usecase for the distinct TimerListener, CancelTimerListener, and StopTimerListener? Wouldn't these be better combined into a single interface with either all three callbacks, or a single callback with a state enum?



    This is the way it was written in the spec, but I think this should be changed to a single interface including all three callbacks.



  • 34. Re: Quartz, timer unification, message inflow RAR
    Weston M. Price Master

    I am moving what is currently in the connector project to the jboss-jca project. This is not in HEAD by default so you will have to

    cd src-dir
    cvs co jboss-jca

    Seems to be a better place for it.

  • 35. Re: Quartz, timer unification, message inflow RAR
    Weston M. Price Master

    As well as moving the Timer spi over to the jboss-jca project, I want to push out the unification task for 5.0.

    I also think that in the interim the Quartz RAR should be removed and not released with 4.0.5.

    Objections?

  • 36. Re: Quartz, timer unification, message inflow RAR
    Carlo de Wolf Master

    Currently the EJB3 HEAD uses Quartz for timer services, so quartz-all-1.5.2.jar is needed in the lib.

    I don't know how EJB3 HEAD relates to the 4.0.5 release.

  • 37. Re: Quartz, timer unification, message inflow RAR
    Dimitris Andreadis Master

    AFAIK, EJB3 HEAD is occasionally backported to JBoss_4_x and from that we get the version that runs in jboss 4.x

    Do you know how transactions are handled through Quartz? Is a timer cancel inside a tx (that hasn't commited yet) visible to other transactions?

  • 38. Re: Quartz, timer unification, message inflow RAR
    Carlo de Wolf Master

    Quartz depends on the data source for transactions. So it would depend on the database used. On Oracle you would probably see the old data from a cached copy, on other database you'll probably have to wait on a row or page lock to gain access to the timer.

  • 39. Re: Quartz, timer unification, message inflow RAR
    Bill Burke Master

     

    "weston.price@jboss.com" wrote:
    As well as moving the Timer spi over to the jboss-jca project, I want to push out the unification task for 5.0.

    I also think that in the interim the Quartz RAR should be removed and not released with 4.0.5.

    Objections?


    Ummm, yes, I have an objection! The Quartz RAR has nothing to do with EJB3 or any timer unification. It is a simple inflow rar to route quartz jobs to an MDB. We already talked about this.

  • 40. Re: Quartz, timer unification, message inflow RAR
    Weston M. Price Master

    No, we didn't. As usual, you talked, I disagreed and you thought things were settled.

    All I am saying is that it won't make the 4.0.5 release. It's not going away. It's a JIRA task right now and we were told that in anticipation of 4.0.5 'clear the deck' of tasks that are not mission criticial.

  • 41. Re: Quartz, timer unification, message inflow RAR
    Weston M. Price Master

    Unless you feel it is adequately tested and documented and can be included in the 4.0.5 release. I have yet to hear anything on the subject from you.

    I for one am not thrilled with a ResourceAdapter that, regardless of whether there are any deployed endpoints or not, decides to fire up a default scheduler. A scheduler that is

    a) Undocumented

    b) Could conflict with any existing schedulers that people may be running in previous release

    c) Consumes resources without even an attempt to be integrated with our existing thread pools etc, etc

    I mean really dude, you are treating this RAR as the 'holy grail' of Timer integration when all it really does, stupidly might I add, is register an MDB listener for a single Quartz job. So I guess if I am intersted in listening to say...3 jobs...do I need 3 endpoints? How about 10? What if I never deploy an endpoint at all...do I still want the Scheduler up and running....doing nothing but showing up in a ThreadDump.

    How about support, have they been told about the adapter and what it means when it starts showing up in profiling info or clients, god forbid, actually try and use it?

    At the very least, I think for 4.0.5, the RAR should go in the docs directory giving the client a choice if they want to deploy the adapter or not.

  • 42. Re: Quartz, timer unification, message inflow RAR
    Dimitris Andreadis Master

    Not really important, but if it's going to be a module on its own I'd prefer a package structure like:

    org.jboss.timer.spi.

    and

    org.jboss.timer (in case there is any end-user provided apis)

    Also, if the timer API is infuenced to any degree by commonj (in addition to our requirements), are we supposed/forced to show this somehow?

  • 43. Re: Quartz, timer unification, message inflow RAR
    Weston M. Price Master

    That's the project/package structure that is set up in connector now. This will be replicated in the jboss-jca stuff when I move things over.

    We decided that a seperate module wasn't necessary, but the package structure you laid out is the one that is currently in use.


  • 44. Re: Quartz, timer unification, message inflow RAR
    Bill Burke Master

     

    "weston.price@jboss.com" wrote:
    Unless you feel it is adequately tested and documented and can be included in the 4.0.5 release. I have yet to hear anything on the subject from you.

    I for one am not thrilled with a ResourceAdapter that, regardless of whether there are any deployed endpoints or not, decides to fire up a default scheduler. A scheduler that is

    a) Undocumented

    b) Could conflict with any existing schedulers that people may be running in previous release

    c) Consumes resources without even an attempt to be integrated with our existing thread pools etc, etc

    I mean really dude, you are treating this RAR as the 'holy grail' of Timer integration when all it really does, stupidly might I add, is register an MDB listener for a single Quartz job. So I guess if I am intersted in listening to say...3 jobs...do I need 3 endpoints? How about 10? What if I never deploy an endpoint at all...do I still want the Scheduler up and running....doing nothing but showing up in a ThreadDump.

    How about support, have they been told about the adapter and what it means when it starts showing up in profiling info or clients, god forbid, actually try and use it?

    At the very least, I think for 4.0.5, the RAR should go in the docs directory giving the client a choice if they want to deploy the adapter or not.



    You are not listening to me. I'm not looking for this to be the "holy grail" for Timers. I just want it available as an optional Quartz deployment mechanism and integration with MDB. That RAR *IS NOT*, I repeat *IS NOT* the basis for any Timer integration.

    All this RAR is a simpler User API for using Quartz so that a quartz job can post to an MDB. Nothing more.

    <ejb-jar>
     <message-driven>
     <ejb-class>my.specific.job.class</ejb-class>
     <activation-spec>
     <name>Cron</name>
     <value>1 2 * * * 4/5</value>
     </activation-spec>
     </message-driven>
    </ejb-jar>
    


    The idea of this RAR is that it is portable to *ANY Java EE Vendor*. Yes, it is bare bones, but it works. And, it is documented somewhat as a EJB3 tutorial.

    To be honest, since all you guys have been assholes about this crap, then do whatever the hell you want. I seriously don't care anymore.


    Bill