[Design of JCA on JBoss] - Re: Quartz, timer unification, message inflow RAR
by weston.price@jboss.com
anonymous wrote :
| The idea of this RAR is that it is portable to *ANY Java EE Vendor*.
|
Of course it is. That's what a RAR is, that's what a RAR gives you.
anonymous wrote :
| All this RAR is a simpler User API for using Quartz so that a quartz job can post to an MDB. Nothing more.
|
Ok, that's fine. Again, and this probably should have been a seperate threaad, but all I was saying is that the JIRA task:
http://jira.jboss.org/jira/browse/JBAS-3206
should be pushed back from the 4.0.5 release. Again, this was in response to QA requesting that all non-critical tasks be moved so we can focus on 5.0.
anonymous wrote :
| Yes, it is bare bones, but it works. And, it is documented somewhat as a EJB3 tutorial.
|
Ok. Did you let anyone know about these tests, the documentation for the adapter? I don't regularly peruse the EJB3 project, so, I am not sure how I would have known this unless you posted this somewhere. If you feel these test are adequate for the 4.0.x release, so be it.
anonymous wrote :
| 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.
|
Sorry you feel that way, but unfortunately the Quartz RAR was checked into the connector project, not in varia, not in EJB3. Believe me, if I could make it go away, I would. However, it ended up 'appearing' right before a 4.0.4 release, and was tentativly slated for the next 4.0.5 release. Again, this is *NOT* about getting rid fo the RAR no matter how much you want to make it look like that. It is about pushing back the task of getting it production ready to a later release.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957430#3957430
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3957430
19 years, 9 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Asynchronous acknowledgements
by timfox
"adrian(a)jboss.org" wrote : You must have some notion of NACKs, otherwise how do you handle
| all the cases that need redeliveries?
|
| e.g. An error during a message listener
|
The spec says that for auto ack or dups_ok then the same message must be redelivered immediately. No need to send anything to the server here since we already have the message on the client and we just retry the onMessage method up to a maximum number of times.
anonymous wrote :
| e.g.2. Closing a CLIENT_ACKNOWLEDGE session without
| acknowledging the messages
|
In this case when the sesssion closes, the server gets the "close session" invocation and knows which messages have been sent to the session but not acked so it just nacks (cancels) them back to the queue. No need to send a nack for each message from client to server.
anonymous wrote :
| e.g.3. closing the receiver there is a race condition
| on the server delivering a message
|
| receiver -> I want a message
| server -> there is none, just wait
| sender -> send message
| server -> queue delivery of message
| receiver -> close()
| delivery -> Oh! The receiver has vanished -> NACK!
|
Right. In this case we send a nack from client to server. In messaging terminology we call it a "cancel" :)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957428#3957428
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3957428
19 years, 9 months
[Design of POJO Server] - Re: VFSDeploymentScanner questions
by scott.stark@jboss.org
I don't see why the hot deployment notion cannot be the baseline tool for deployment, and still have integration with the ProfileService. My concern with regard to leaving the hot deployment notion as something completely separate from the ProfileService is that it won't be used. If we wan't a similar prod compatible ease of use deployment, at least for single node systems, there will have to be some service that integrates hot deployment type of additions to the ProfileService. As far as I can see the only reason not to look at building the hot deployment service on top of the ProfileService would be the additional time it takes to complete an initial implementation. I can create a MainDeployer based implementation as a starting point to allow jboss5 to get to the point of deploying the existing configurations and look at an alternate implementation independently.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957426#3957426
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3957426
19 years, 9 months
[Design of JCA on JBoss] - Re: Quartz, timer unification, message inflow RAR
by bill.burke@jboss.com
"weston.price(a)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
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3957417#3957417
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3957417
19 years, 9 months