[jboss-dev-forums] [EJB 3.0 Development] - Re: HornetQ JCA Adapter question

Tue Sep 15 17:27:35 EDT 2009

I had a conversation about the JCA adapter today with Carlo.

Basically Carlo agrees with Jesper.

Here is the transcript for future reference:

anonymous wrote : 
  | (03:33:56 PM) wolfc: clebert: delivering multiple message within a single tx is against spec, so I'm very curious how others implement this
  | (03:34:52 PM) clebert: wolfc: it's probably against the spec...
  | (03:34:52 PM) clebert: also.. I believe others support sub-transactions... so I guess they used that as a way to sneak in the rule on Specj
  | (03:35:10 PM) clebert: wolfc: it's against the spec.. but useful...
  | (03:35:22 PM) clebert: wolfc: IMO actually: it should be made as part of the spec somehow
  | (03:35:32 PM) clebert: say.. you're doing this:
  | (03:35:32 PM) clebert: (forget MDBs)
  | (03:35:39 PM) clebert: pseudo code coming... sec:
  | (03:36:07 PM) wolfc: forget MDBs means I'm off the hook :-P
  | (03:36:30 PM) clebert: int i = 0;
  | (03:36:30 PM) clebert: while (true)
  | (03:36:30 PM) clebert: {
  | (03:36:30 PM) clebert:    i++
  | (03:36:30 PM) clebert:    msg = consumer.receive();
  | (03:36:30 PM) clebert:    if (i == 500) tx.commit();
  | (03:36:30 PM) clebert: }
  | (03:36:38 PM) clebert: if a rollback happens here.. everything would be rolled back
  | (03:36:45 PM) clebert: and everything redelivered
  | (03:37:11 PM) clebert: most people will do this kind of thing when not using MDBs.. but have to do single syncs when doing MDBs
  | (03:39:18 PM) clebert: wolfc: I said forget MDBs just as an example...
  | (03:39:19 PM) clebert: when not using MDBs users can do this kind of thing... but when on MDBs they have to use single-syncs
  | (03:39:34 PM) wolfc: but we're not talking simple MessageReceivers, we're talking JCA
  | (03:40:06 PM) clebert: wolfc: yes.... I know.. this should be part of the JCA spec somehow
  | (03:40:19 PM) clebert: wolfc: I mean.. IMHO
  | (03:42:40 PM) wolfc: clebert: the only thing I've been seeing is that such a feature gives customers headaches.
  | (03:42:53 PM) wolfc: for example: https://jira.jboss.org/jira/browse/JBPAPP-2260
  | (03:43:48 PM) wolfc: basically you see support case where people complain about messages being unduly redelivered
  | (03:44:19 PM) clebert: wolfc: well.. that was a bug.. right?
  | (03:44:19 PM) clebert: Bugs are bugs :-)
  | (03:44:53 PM) clebert: wolfc: It's very common users just using MDBs on the Application Server... 
  | (03:44:53 PM) clebert: But the performance for MDB is horrible because of that
  | (03:45:11 PM) wolfc: yeah, the bug was batching
  | (03:46:11 PM) clebert: wolfc: if we use batching... we would need to use a single consumer on the MDB... and the user would have to use it carefully.
  | (03:47:05 PM) wolfc: clebert: right, which is horrible for them to implement and horrible to tune
  | (03:47:28 PM) clebert: wolfc: for them .. you mean.. customers?
  | (03:47:34 PM) wolfc: yes
  | (03:48:11 PM) clebert: wolfc: that would be the same as doing the pseudo code above... the user would have the choice of doing it through MDBs
  | (03:48:35 PM) clebert: wolfc: right now if you want performance on receiving messages.. we have to say don't use MDBs
  | (03:49:09 PM) wolfc: clebert: what's faster: 1 consumer doing 100 batched or 100 MDBs?
  | (03:50:16 PM) clebert: wolfc: it depends on the use case.... 
  | (03:50:16 PM) clebert: some users need strict ordering.. that means you can only have 1 consumer.
  | (03:51:35 PM) wolfc: I think I see the trick: Delivering batches of messages to each MDB endpoint can improve performance particularly when used with Acknowledge mode set to Duplicates-ok auto-acknowledge.
  | (03:51:44 PM) bobmcw_ left the room (quit: Remote closed the connection).
  | (03:51:46 PM) clebert: wolfc: from Messaging point of view... 100 consumers would scale.. but on the Application server that would mean 100 threads.... what would end up on more resources.
  | (03:51:46 PM) clebert: at the end if you need performance we just say.. don't use MDBs
  | (03:52:38 PM) wolfc: clebert: that's on WAS, but it doesn't say anything about the tx
  | (03:53:22 PM) clebert: wolfc: yeah... Duplicates-ok is fine.. but most users also need to control transactions...
  | (03:53:22 PM) clebert: Expand that loop to:
  | (03:53:22 PM) clebert: loop
  | (03:53:22 PM) clebert: {
  | (03:53:22 PM) clebert:     msg = consumer.receve();
  | (03:53:22 PM) clebert:     if (counter++ == 500) xa.commit;
  | (03:53:22 PM) clebert:     db.inserts, updates...etc;
  | (03:53:22 PM) clebert: }
  | (03:53:23 PM) wolfc: clebert: still if the ack mode is dups-ok we have some leeway
  | (03:53:30 PM) clebert: say.. a store is receiving a new table or something...
  | (03:53:38 PM) clebert: if you commit msg by msg.. that would take forever
  | (03:54:35 PM) clebert: right now.. the user can only do this by hand with a consumer.. without using MDBs
  | (03:55:14 PM) clebert: well.. the user could go around.. like.. a msg saying... get the new table.. on the onMessage it starts a consumer on another queue
  | (03:55:18 PM) kkhan left the room (quit: ).
  | (03:56:50 PM) clebert: wolfc: that's something I know BEA and WebSphere have
  | (03:58:41 PM) wolfc: clebert: where does it say that?
  | (03:58:55 PM) clebert: sec
  | (04:00:33 PM) clebert: wolfc: I read both docs once.. I didn't want to link to our JIRA as I didn't want to look like plagiarism 
  | (04:00:46 PM) clebert: wolfc: let me see if I can find it here real quick
  | (04:02:28 PM) clebert: wolfc: http://74.125.155.132/search?q=cache:kp8szn4Jc6kJ:e-docs.bea.com/wls/docs103/ejb/message_beans.html+grouping+transactions+MDB+WebLogic&cd=1&hl=en&ct=clnk&gl=us
  | (04:02:28 PM) clebert: It disapperared.. I could only read it from the cache
  | (04:02:34 PM) clebert: look for Transaction Batching of MDBs
  | (04:03:54 PM) wolfc: clebert: okay the bea doc at least explicitly states multiple msgs / tx
  | (04:04:41 PM) clebert: wolfc: I don't care much about the spec on this case...  all I care is I think it's a valid use case...
  | (04:04:41 PM) clebert: Maybe this should be included on the spec.. that's my point
  | (04:05:36 PM) wolfc: clebert: if we want this it should be part of the proxy endpoint, not part of the RA
  | (04:06:06 PM) wolfc: hmm, no that's not possible
  | (04:06:32 PM) clebert: wolfc: what's not possible? add it to the spec?
  | (04:06:54 PM) wolfc: no, make it part of the proxy endpoint
  | (04:08:01 PM) wolfc: clebert: the RA could do option B, but do multiple deliveries instead of 1
  | (04:08:15 PM) clebert: wolfc: we are doing option B ATM.
  | (04:08:26 PM) clebert: wolfc: we have actually an open issue with TCCL ATM
  | (04:08:30 PM) wolfc: clebert: option A is 1 msg / tx
  | (04:08:38 PM) clebert: wolfc: that' s why we are asking you to look at that thread
  | (04:08:52 PM) bstansb_afk is now known as bstansberry
  | (04:09:17 PM) bstansberry: any maven lovers know any place maven caches snapshots besides in ~/.m2/repository ?
  | (04:09:24 PM) clebert: wolfc: the batch transaction will be probably fixed later.. it's a nice to have feature
  | (04:10:36 PM) clebert: wolfc: but the TCCL is a current bug we have.. any help would be appreciated on that EJB3 dev forum thread
  | (04:10:36 PM) clebert: Jesper said both options need to be on the proxy endpoint.. but like what you just said goes against that I think
  | (04:13:51 PM) rruss left the room (quit: Read error: 110 (Connection timed out)).
  | (04:15:34 PM) wolfc: clebert: there are more points where the proper tccl isn't set in ejb3, so it's not an isolated problem
  | (04:15:47 PM) wolfc: clebert: and the current proxy endpoint implementation is very messy
  | (04:15:59 PM) wolfc: clebert: hacked together to work with JBossMQ
  | (04:17:07 PM) clebert: wolfc: we are adding a hack in our code...
  | (04:17:07 PM) clebert: we created a property hackOn
  | (04:17:07 PM) clebert: If (hackOn) setTCCL(endpoing.getClass().getClassLoader());
  | (04:17:07 PM) clebert: Or something like that
  | (04:17:11 PM) wolfc: clebert: for the moment just use option B and you're set to go
  | (04:17:25 PM) rruss [n=rruss at redhat/jboss/rruss] entered the room.
  | (04:17:25 PM) mode (+v rruss ) by ChanServ
  | (04:17:50 PM) clebert: wolfc: option B .. but what about beforeDelivery and afterDelivery...
  | (04:17:50 PM) clebert: we don't need to call that, right?
  | (04:17:50 PM) clebert: we can just use the hack and set the TCCL ourselves?
  | (04:18:24 PM) wolfc: clebert: don't make matters worse.
  | (04:18:24 PM) wolfc: clebert: just use option B
  | (04:18:34 PM) wolfc: I don't see why that should be a problem
  | (04:20:19 PM) wolfc: clebert: basically option A RAs don't function and since the proxy endpoint code has been duplicated just about everywhere you'll run into more issues with other components.
  | (04:21:30 PM) clebert: wolfc: Andy is the one doing it... we needed more control over transaction.. so we are using a different option...
  | (04:21:42 PM) clebert: (I don't recall if A or B.. all I know is the one where you don't call beforeDelivery)
  | (04:21:45 PM) wolfc: clebert: the RA can never control the tx
  | (04:22:34 PM) clebert: wolfc: can you input that on the thread pls.. so Andy will get it for sure?
  | (04:22:38 PM) wolfc: I should say: the RA can never control the tx directly
  | (04:24:56 PM) wolfc: clebert: jesper already put that in the thread
  | (04:25:20 PM) clebert: wolfc: ok.. I was just wondering if what we were discussing about batching would still apply on that...
  | (04:25:55 PM) wolfc: clebert: yep it'll. In that case we'll use option B, but do multiple deliveries and tell the proxy endpoint to not complain about it.
  | (04:26:21 PM) clebert: wolfc: ok
  | (04:26:31 PM) clebert: wolfc: I will put this conversation on that thread if you don't mind
  | 

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255404#4255404

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4255404