Question on MDB processing

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Question on MDB processing

almos
Hi,

When JMS message goes to the MDB deployed in TomEE there are a lot of log entries like these:

INFO: Removing non-required WorkContextHandler with no context: org.apache.geronimo.connector.work.TransactionContextHandler@19647f24
Mar 23, 2013 2:25:21 PM org.apache.geronimo.connector.work.WorkerContext run
INFO: Removing non-required WorkContextHandler with no context: org.apache.openejb.core.security.SecurityContextHandler@14d72182
Mar 23, 2013 2:25:21 PM org.apache.geronimo.connector.work.WorkerContext run
INFO: Removing non-required WorkContextHandler with no context: org.apache.geronimo.connector.work.HintsContextHandler@37d8e87e
Mar 23, 2013 2:25:21 PM org.apache.geronimo.connector.work.WorkerContext run

So there's a lot of things going behind the scenes according to EE specs.
For one of the tasks I need to implement I would like to reduce overhead of MDB processing and somehow switch off transaction support and other handlers/interceptors on MDBs in case of using embedded ActiveMQ with vm:// type of transport.
Which broker/TomEE configuration options/MDB annotations you may recommend to reduce processing overhead as much as possible?
Is it even somehow possible or I should just use some lightweight event bus alternatives like Akka or whatever else similar?

Regards,
Alex
Reply | Threaded
Open this post in threaded view
|

Re: Question on MDB processing

Romain Manni-Bucau
@TransactionAttribute or @TransactionManagement are here for that

depending on the bus type you want using @Asynchronous + a queue can be
more efficient

*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*



2013/3/23 almos <[hidden email]>

> Hi,
>
> When JMS message goes to the MDB deployed in TomEE there are a lot of log
> entries like these:
>
> INFO: Removing non-required WorkContextHandler with no context:
> org.apache.geronimo.connector.work.TransactionContextHandler@19647f24
> Mar 23, 2013 2:25:21 PM org.apache.geronimo.connector.work.WorkerContext
> run
> INFO: Removing non-required WorkContextHandler with no context:
> org.apache.openejb.core.security.SecurityContextHandler@14d72182
> Mar 23, 2013 2:25:21 PM org.apache.geronimo.connector.work.WorkerContext
> run
> INFO: Removing non-required WorkContextHandler with no context:
> org.apache.geronimo.connector.work.HintsContextHandler@37d8e87e
> Mar 23, 2013 2:25:21 PM org.apache.geronimo.connector.work.WorkerContext
> run
>
> So there's a lot of things going behind the scenes according to EE specs.
> For one of the tasks I need to implement I would like to reduce overhead of
> MDB processing and somehow switch off transaction support and other
> handlers/interceptors on MDBs in case of using embedded ActiveMQ with vm://
> type of transport.
> Which broker/TomEE configuration options/MDB annotations you may recommend
> to reduce processing overhead as much as possible?
> Is it even somehow possible or I should just use some lightweight event bus
> alternatives like Akka or whatever else similar?
>
> Regards,
> Alex
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/Question-on-MDB-processing-tp4661685.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>
Reply | Threaded
Open this post in threaded view
|

Re: Question on MDB processing

smithh032772
I have experienced the same in my tomee logs that almos is reporting here,
since I am using 'simple MDB' approach via Tomee/ActiveMQ. Actually, I am
quite please and all of that 'stuff' in the log files is not much of a
concern to me.

@Asynchronous doesn't meet my requirements, or maybe I just did not know
how to handle @Asynchronous after it completes the tasks. It seems to end
up in some piece of my code, and some old piece of code seems to want to be
executed after @Asynchronous returns.

With that said, TomEE/ActiveMQ meets my requirements, but Romain, can you
please explain your response below to almos's question? Do you have an
example on how to use, so the log line will not be filled up with all those
lines related to ActiveMQ, Geronimo, etc...?

"@TransactionAttribute or @TransactionManagement are here for that"



On Sat, Mar 23, 2013 at 4:21 PM, Romain Manni-Bucau
<[hidden email]>wrote:

> @TransactionAttribute or @TransactionManagement are here for that
>
> depending on the bus type you want using @Asynchronous + a queue can be
> more efficient
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> *Blog: **http://rmannibucau.wordpress.com/*<
> http://rmannibucau.wordpress.com/>
> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> *Github: https://github.com/rmannibucau*
>
>
>
> 2013/3/23 almos <[hidden email]>
>
> > Hi,
> >
> > When JMS message goes to the MDB deployed in TomEE there are a lot of log
> > entries like these:
> >
> > INFO: Removing non-required WorkContextHandler with no context:
> > org.apache.geronimo.connector.work.TransactionContextHandler@19647f24
> > Mar 23, 2013 2:25:21 PM org.apache.geronimo.connector.work.WorkerContext
> > run
> > INFO: Removing non-required WorkContextHandler with no context:
> > org.apache.openejb.core.security.SecurityContextHandler@14d72182
> > Mar 23, 2013 2:25:21 PM org.apache.geronimo.connector.work.WorkerContext
> > run
> > INFO: Removing non-required WorkContextHandler with no context:
> > org.apache.geronimo.connector.work.HintsContextHandler@37d8e87e
> > Mar 23, 2013 2:25:21 PM org.apache.geronimo.connector.work.WorkerContext
> > run
> >
> > So there's a lot of things going behind the scenes according to EE specs.
> > For one of the tasks I need to implement I would like to reduce overhead
> of
> > MDB processing and somehow switch off transaction support and other
> > handlers/interceptors on MDBs in case of using embedded ActiveMQ with
> vm://
> > type of transport.
> > Which broker/TomEE configuration options/MDB annotations you may
> recommend
> > to reduce processing overhead as much as possible?
> > Is it even somehow possible or I should just use some lightweight event
> bus
> > alternatives like Akka or whatever else similar?
> >
> > Regards,
> > Alex
> >
> >
> >
> > --
> > View this message in context:
> >
> http://openejb.979440.n4.nabble.com/Question-on-MDB-processing-tp4661685.html
> > Sent from the OpenEJB User mailing list archive at Nabble.com.
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Question on MDB processing

Romain Manni-Bucau
well about logs it should jus tbe configured but will not prevent tx to be
handled ;)

@Async is great and you can handle after return part usnig AsyncResult.

*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*



2013/3/23 Howard W. Smith, Jr. <[hidden email]>

> I have experienced the same in my tomee logs that almos is reporting here,
> since I am using 'simple MDB' approach via Tomee/ActiveMQ. Actually, I am
> quite please and all of that 'stuff' in the log files is not much of a
> concern to me.
>
> @Asynchronous doesn't meet my requirements, or maybe I just did not know
> how to handle @Asynchronous after it completes the tasks. It seems to end
> up in some piece of my code, and some old piece of code seems to want to be
> executed after @Asynchronous returns.
>
> With that said, TomEE/ActiveMQ meets my requirements, but Romain, can you
> please explain your response below to almos's question? Do you have an
> example on how to use, so the log line will not be filled up with all those
> lines related to ActiveMQ, Geronimo, etc...?
>
> "@TransactionAttribute or @TransactionManagement are here for that"
>
>
>
> On Sat, Mar 23, 2013 at 4:21 PM, Romain Manni-Bucau
> <[hidden email]>wrote:
>
> > @TransactionAttribute or @TransactionManagement are here for that
> >
> > depending on the bus type you want using @Asynchronous + a queue can be
> > more efficient
> >
> > *Romain Manni-Bucau*
> > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > *Blog: **http://rmannibucau.wordpress.com/*<
> > http://rmannibucau.wordpress.com/>
> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > *Github: https://github.com/rmannibucau*
> >
> >
> >
> > 2013/3/23 almos <[hidden email]>
> >
> > > Hi,
> > >
> > > When JMS message goes to the MDB deployed in TomEE there are a lot of
> log
> > > entries like these:
> > >
> > > INFO: Removing non-required WorkContextHandler with no context:
> > > org.apache.geronimo.connector.work.TransactionContextHandler@19647f24
> > > Mar 23, 2013 2:25:21 PM
> org.apache.geronimo.connector.work.WorkerContext
> > > run
> > > INFO: Removing non-required WorkContextHandler with no context:
> > > org.apache.openejb.core.security.SecurityContextHandler@14d72182
> > > Mar 23, 2013 2:25:21 PM
> org.apache.geronimo.connector.work.WorkerContext
> > > run
> > > INFO: Removing non-required WorkContextHandler with no context:
> > > org.apache.geronimo.connector.work.HintsContextHandler@37d8e87e
> > > Mar 23, 2013 2:25:21 PM
> org.apache.geronimo.connector.work.WorkerContext
> > > run
> > >
> > > So there's a lot of things going behind the scenes according to EE
> specs.
> > > For one of the tasks I need to implement I would like to reduce
> overhead
> > of
> > > MDB processing and somehow switch off transaction support and other
> > > handlers/interceptors on MDBs in case of using embedded ActiveMQ with
> > vm://
> > > type of transport.
> > > Which broker/TomEE configuration options/MDB annotations you may
> > recommend
> > > to reduce processing overhead as much as possible?
> > > Is it even somehow possible or I should just use some lightweight event
> > bus
> > > alternatives like Akka or whatever else similar?
> > >
> > > Regards,
> > > Alex
> > >
> > >
> > >
> > > --
> > > View this message in context:
> > >
> >
> http://openejb.979440.n4.nabble.com/Question-on-MDB-processing-tp4661685.html
> > > Sent from the OpenEJB User mailing list archive at Nabble.com.
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Question on MDB processing

smithh032772
On Sat, Mar 23, 2013 at 5:23 PM, Romain Manni-Bucau
<[hidden email]>wrote:

> well about logs it should jus tbe configured but will not prevent tx to be
> handled ;)
>

Not understood.


>
> @Async is great and you can handle after return part usnig AsyncResult.
>
>
Understood. I have some code in place that is ready to use. I stopped using
it, but I may revisit. I think I remember seeing you recommend
@Asynchronous (over MDB/JMS) some time ago, and i definitely saw David
Blevins with a nice code example on stackoverflow.com; that is what really
motivated me to use/add that to my web app.

I am so pleased with tomee 'simple MDB', i may not even try to use @Async.
we'll see. :)
Reply | Threaded
Open this post in threaded view
|

Re: Question on MDB processing

Romain Manni-Bucau
if the log line bother you but not the transaction just configure logs to
not write it.


about mdb/async: if async is needed you dont need the overhead introduced
by JMS/AMQ (serialization...)

*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*



2013/3/23 Howard W. Smith, Jr. <[hidden email]>

> On Sat, Mar 23, 2013 at 5:23 PM, Romain Manni-Bucau
> <[hidden email]>wrote:
>
> > well about logs it should jus tbe configured but will not prevent tx to
> be
> > handled ;)
> >
>
> Not understood.
>
>
> >
> > @Async is great and you can handle after return part usnig AsyncResult.
> >
> >
> Understood. I have some code in place that is ready to use. I stopped using
> it, but I may revisit. I think I remember seeing you recommend
> @Asynchronous (over MDB/JMS) some time ago, and i definitely saw David
> Blevins with a nice code example on stackoverflow.com; that is what really
> motivated me to use/add that to my web app.
>
> I am so pleased with tomee 'simple MDB', i may not even try to use @Async.
> we'll see. :)
>
Reply | Threaded
Open this post in threaded view
|

Re: Question on MDB processing

smithh032772
On Sat, Mar 23, 2013 at 5:35 PM, Romain Manni-Bucau
<[hidden email]>wrote:

> if the log line bother you but not the transaction just configure logs to
> not write it.
>
> Understood. It's definitely not a bother to me; it's more of a
'nice-to-have'. :)


>
> about mdb/async: if async is needed you dont need the overhead introduced
> by JMS/AMQ (serialization...)
>
>
interesting... i see no overhead at all. JMS/AMQ handling multiple message
queues for me already and hoping to add more. I have even decreased the
amount of Xmx needed by my app (did that some months ago); had it at 4096,
but now have it at 1024, and honestly, jvisualvm never tells me that app is
coming close to 1024.

i have experienced and seen a delay when @Schedule and JMS/AMQ is running
as it is doing multiple things... IMAP connection to get emails and insert
data into database. when i had my old production server, the database would
deadlock, but since the new server is faster and we have faster internet
connection now... i only see a slight delay, if i'm in web app while
@Schedule and JMS/AMQ doing its thing. i think the database may be where
the bottleneck is; it's definitely not the lack of CPU, network connection,
etc...

i still may have a thing or two i need to learn about @Stateless inserting
data into database via @Schedule and JMS/AMQ...to avoid deadlock. I did set
@AccessTimeout to 2 minutes on @Singleton bean, even though the lock never
seems to take that long. With the code and configuration in place, this all
is working well and I have seen 'no' deadlock errors in the log as I did
when we had the older/slower server. :)
Reply | Threaded
Open this post in threaded view
|

Re: Question on MDB processing

Romain Manni-Bucau
just to be sure: @Schedule != @Asynchronous

*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*



2013/3/23 Howard W. Smith, Jr. <[hidden email]>

> On Sat, Mar 23, 2013 at 5:35 PM, Romain Manni-Bucau
> <[hidden email]>wrote:
>
> > if the log line bother you but not the transaction just configure logs to
> > not write it.
> >
> > Understood. It's definitely not a bother to me; it's more of a
> 'nice-to-have'. :)
>
>
> >
> > about mdb/async: if async is needed you dont need the overhead introduced
> > by JMS/AMQ (serialization...)
> >
> >
> interesting... i see no overhead at all. JMS/AMQ handling multiple message
> queues for me already and hoping to add more. I have even decreased the
> amount of Xmx needed by my app (did that some months ago); had it at 4096,
> but now have it at 1024, and honestly, jvisualvm never tells me that app is
> coming close to 1024.
>
> i have experienced and seen a delay when @Schedule and JMS/AMQ is running
> as it is doing multiple things... IMAP connection to get emails and insert
> data into database. when i had my old production server, the database would
> deadlock, but since the new server is faster and we have faster internet
> connection now... i only see a slight delay, if i'm in web app while
> @Schedule and JMS/AMQ doing its thing. i think the database may be where
> the bottleneck is; it's definitely not the lack of CPU, network connection,
> etc...
>
> i still may have a thing or two i need to learn about @Stateless inserting
> data into database via @Schedule and JMS/AMQ...to avoid deadlock. I did set
> @AccessTimeout to 2 minutes on @Singleton bean, even though the lock never
> seems to take that long. With the code and configuration in place, this all
> is working well and I have seen 'no' deadlock errors in the log as I did
> when we had the older/slower server. :)
>
Reply | Threaded
Open this post in threaded view
|

Re: Question on MDB processing

smithh032772
On Sat, Mar 23, 2013 at 5:55 PM, Romain Manni-Bucau
<[hidden email]>wrote:

> just to be sure: @Schedule != @Asynchronous
>
>
True/understood. hahaha!

My point is this... since i had issues using @Asynchronous, it is hard
going back to @Asynchronous since i'm loving AMQ/JMS. :)

I think I heard you and/or others say that JMS is old technology (java ee
5), and I know @Asynchronous is java ee 6, so i trust @asynchronous can do
the job, but i even heard that @asynchronous is not good to use in JSF or
servlet (request-based) apps.
Reply | Threaded
Open this post in threaded view
|

Re: Question on MDB processing

Romain Manni-Bucau
never said it was old in a negative way

JMS is awesome for REMOTE and ASYNC stuff.

*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*



2013/3/23 Howard W. Smith, Jr. <[hidden email]>

> On Sat, Mar 23, 2013 at 5:55 PM, Romain Manni-Bucau
> <[hidden email]>wrote:
>
> > just to be sure: @Schedule != @Asynchronous
> >
> >
> True/understood. hahaha!
>
> My point is this... since i had issues using @Asynchronous, it is hard
> going back to @Asynchronous since i'm loving AMQ/JMS. :)
>
> I think I heard you and/or others say that JMS is old technology (java ee
> 5), and I know @Asynchronous is java ee 6, so i trust @asynchronous can do
> the job, but i even heard that @asynchronous is not good to use in JSF or
> servlet (request-based) apps.
>
Reply | Threaded
Open this post in threaded view
|

Re: Question on MDB processing

smithh032772
On Sat, Mar 23, 2013 at 6:05 PM, Romain Manni-Bucau
<[hidden email]>wrote:

> never said it was old in a negative way
>
> Agreed! :)


> JMS is awesome for REMOTE and ASYNC stuff.
>
> Agreed! :)
Reply | Threaded
Open this post in threaded view
|

Re: Question on MDB processing

almos
In reply to this post by Romain Manni-Bucau
Romain,

Thanks for the response.
Basically I am usually doing this with the help of the blocking queue:

JMS message -> MDB -> EJB singleton method call that puts JMS message contents to a blocking queue

this blocking queue is processed within an EJB singleton in background multithreaded manner. As blocking queue combined with a set of threads listening on it works as a good local "load balancer".

I was just asking about minimizing transactional overhead.
Which approach from the container (TomEE) perspective would have less overhead related to the transactional processing:

1) TransactionManagement=CMT + TransactionAttribute=NOT_SUPPORTED
2) TransactionManagement=BMT

?

Regards,
Alex
Reply | Threaded
Open this post in threaded view
|

Re: Question on MDB processing

Romain Manni-Bucau
I'd use 1 + SUPPORTS but 2 works fine too
Le 24 mars 2013 15:01, "almos" <[hidden email]> a écrit :

> Romain,
>
> Thanks for the response.
> Basically I am usually doing this with the help of the blocking queue:
>
> JMS message -> MDB -> EJB singleton method call that puts JMS message
> contents to a blocking queue
>
> this blocking queue is processed within an EJB singleton in background
> multithreaded manner. As blocking queue combined with a set of threads
> listening on it works as a good local "load balancer".
>
> I was just asking about minimizing transactional overhead.
> Which approach from the container (TomEE) perspective would have less
> overhead related to the transactional processing:
>
> 1) TransactionManagement=CMT + TransactionAttribute=NOT_SUPPORTED
> 2) TransactionManagement=BMT
>
> ?
>
> Regards,
> Alex
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/Question-on-MDB-processing-tp4661685p4661697.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>
Reply | Threaded
Open this post in threaded view
|

Re: Question on MDB processing

Bjorn Danielsson
In reply to this post by smithh032772
Interesting, I went the opposite way, from JMS to @Asynchronous.

I began using JMS for asynchronous requests that were required
to be transactional and reliable. This worked great during
initial development, first with OpenMQ in GlassFish and then
with ActiveMQ in OpenEJB/TomEE. But when I started testing
ActiveMQ failover configurations under heavy loads, I started
getting lost messages and hung JMS connections.

So after struggling for a while I ended up rolling my own
persistent queue in SQL, and used @Asynchronous for the request
dispatch. That turned out to solve all of my problems, and the
overall configuration also become notably simpler.

--
Bjorn Danielsson
Cuspy Code AB


"Howard W. Smith, Jr." <[hidden email]> wrote:

> On Sat, Mar 23, 2013 at 5:55 PM, Romain Manni-Bucau
> <[hidden email]>wrote:
>
>> just to be sure: @Schedule != @Asynchronous
>>
>>
> True/understood. hahaha!
>
> My point is this... since i had issues using @Asynchronous, it is hard
> going back to @Asynchronous since i'm loving AMQ/JMS. :)
>
> I think I heard you and/or others say that JMS is old technology (java ee
> 5), and I know @Asynchronous is java ee 6, so i trust @asynchronous can do
> the job, but i even heard that @asynchronous is not good to use in JSF or
> servlet (request-based) apps.
Reply | Threaded
Open this post in threaded view
|

Re: Question on MDB processing

Romain Manni-Bucau
Yes, you squeezed the network layer, you avoided network problems ;)
Le 24 mars 2013 18:12, "Bjorn Danielsson" <[hidden email]>
a écrit :

> Interesting, I went the opposite way, from JMS to @Asynchronous.
>
> I began using JMS for asynchronous requests that were required
> to be transactional and reliable. This worked great during
> initial development, first with OpenMQ in GlassFish and then
> with ActiveMQ in OpenEJB/TomEE. But when I started testing
> ActiveMQ failover configurations under heavy loads, I started
> getting lost messages and hung JMS connections.
>
> So after struggling for a while I ended up rolling my own
> persistent queue in SQL, and used @Asynchronous for the request
> dispatch. That turned out to solve all of my problems, and the
> overall configuration also become notably simpler.
>
> --
> Bjorn Danielsson
> Cuspy Code AB
>
>
> "Howard W. Smith, Jr." <[hidden email]> wrote:
> > On Sat, Mar 23, 2013 at 5:55 PM, Romain Manni-Bucau
> > <[hidden email]>wrote:
> >
> >> just to be sure: @Schedule != @Asynchronous
> >>
> >>
> > True/understood. hahaha!
> >
> > My point is this... since i had issues using @Asynchronous, it is hard
> > going back to @Asynchronous since i'm loving AMQ/JMS. :)
> >
> > I think I heard you and/or others say that JMS is old technology (java ee
> > 5), and I know @Asynchronous is java ee 6, so i trust @asynchronous can
> do
> > the job, but i even heard that @asynchronous is not good to use in JSF or
> > servlet (request-based) apps.
>
Reply | Threaded
Open this post in threaded view
|

Re: Question on MDB processing

Bjorn Danielsson
Well, I still have networking between my two (for failover)
TomEE servers and the SQL service that holds the queue and
commits the transactions. But I eliminated a middle-man :)

--
Bjorn Danielsson
Cuspy Code AB


Romain Manni-Bucau <[hidden email]> wrote:

> Yes, you squeezed the network layer, you avoided network problems ;)
> Le 24 mars 2013 18:12, "Bjorn Danielsson" <[hidden email]>
> a écrit :
>
>> Interesting, I went the opposite way, from JMS to @Asynchronous.
>>
>> I began using JMS for asynchronous requests that were required
>> to be transactional and reliable. This worked great during
>> initial development, first with OpenMQ in GlassFish and then
>> with ActiveMQ in OpenEJB/TomEE. But when I started testing
>> ActiveMQ failover configurations under heavy loads, I started
>> getting lost messages and hung JMS connections.
>>
>> So after struggling for a while I ended up rolling my own
>> persistent queue in SQL, and used @Asynchronous for the request
>> dispatch. That turned out to solve all of my problems, and the
>> overall configuration also become notably simpler.
>>
>> --
>> Bjorn Danielsson
>> Cuspy Code AB
>>
>>
>> "Howard W. Smith, Jr." <[hidden email]> wrote:
>> > On Sat, Mar 23, 2013 at 5:55 PM, Romain Manni-Bucau
>> > <[hidden email]>wrote:
>> >
>> >> just to be sure: @Schedule != @Asynchronous
>> >>
>> >>
>> > True/understood. hahaha!
>> >
>> > My point is this... since i had issues using @Asynchronous, it is hard
>> > going back to @Asynchronous since i'm loving AMQ/JMS. :)
>> >
>> > I think I heard you and/or others say that JMS is old technology (java ee
>> > 5), and I know @Asynchronous is java ee 6, so i trust @asynchronous can
>> do
>> > the job, but i even heard that @asynchronous is not good to use in JSF or
>> > servlet (request-based) apps.
>>
Reply | Threaded
Open this post in threaded view
|

Re: Question on MDB processing

smithh032772
That is good to know, thanks for sharing! And you squeezed a bit more
information/details out of Romain... i couldn't squeeze the following line
out of him earlier... lol

> Yes, you squeezed the network layer, you avoided network problems ;)


On Sun, Mar 24, 2013 at 1:35 PM, Bjorn Danielsson <
[hidden email]> wrote:

> Well, I still have networking between my two (for failover)
> TomEE servers and the SQL service that holds the queue and
> commits the transactions. But I eliminated a middle-man :)
>
> --
> Bjorn Danielsson
> Cuspy Code AB
>
>
> Romain Manni-Bucau <[hidden email]> wrote:
> > Yes, you squeezed the network layer, you avoided network problems ;)
> > Le 24 mars 2013 18:12, "Bjorn Danielsson" <
> [hidden email]>
> > a écrit :
> >
> >> Interesting, I went the opposite way, from JMS to @Asynchronous.
> >>
> >> I began using JMS for asynchronous requests that were required
> >> to be transactional and reliable. This worked great during
> >> initial development, first with OpenMQ in GlassFish and then
> >> with ActiveMQ in OpenEJB/TomEE. But when I started testing
> >> ActiveMQ failover configurations under heavy loads, I started
> >> getting lost messages and hung JMS connections.
> >>
> >> So after struggling for a while I ended up rolling my own
> >> persistent queue in SQL, and used @Asynchronous for the request
> >> dispatch. That turned out to solve all of my problems, and the
> >> overall configuration also become notably simpler.
> >>
> >> --
> >> Bjorn Danielsson
> >> Cuspy Code AB
> >>
> >>
> >> "Howard W. Smith, Jr." <[hidden email]> wrote:
> >> > On Sat, Mar 23, 2013 at 5:55 PM, Romain Manni-Bucau
> >> > <[hidden email]>wrote:
> >> >
> >> >> just to be sure: @Schedule != @Asynchronous
> >> >>
> >> >>
> >> > True/understood. hahaha!
> >> >
> >> > My point is this... since i had issues using @Asynchronous, it is hard
> >> > going back to @Asynchronous since i'm loving AMQ/JMS. :)
> >> >
> >> > I think I heard you and/or others say that JMS is old technology
> (java ee
> >> > 5), and I know @Asynchronous is java ee 6, so i trust @asynchronous
> can
> >> do
> >> > the job, but i even heard that @asynchronous is not good to use in
> JSF or
> >> > servlet (request-based) apps.
> >>
>
Reply | Threaded
Open this post in threaded view
|

Re: Question on MDB processing

smithh032772
In reply to this post by Bjorn Danielsson
Bjorn, for some time now, i've been wondering how to have 2 separate TomEE
servers (for failover) and one copy of your database per  TomEE? are you
replicating database via tomee/tomcat session replication?

sometime ago, i searched google about this, but honestly... i don't
understand how to replicate database in cluster environment. i am using
eclipselink as jpa provider, and i think i saw something related to
cluster/replication via eclipselink. i couldn't find any blogs or anything
out there talking about this subject much. :(


On Sun, Mar 24, 2013 at 1:35 PM, Bjorn Danielsson <
[hidden email]> wrote:

> Well, I still have networking between my two (for failover)
> TomEE servers and the SQL service that holds the queue and
> commits the transactions. But I eliminated a middle-man :)
>
> --
> Bjorn Danielsson
> Cuspy Code AB
>
>
> Romain Manni-Bucau <[hidden email]> wrote:
> > Yes, you squeezed the network layer, you avoided network problems ;)
> > Le 24 mars 2013 18:12, "Bjorn Danielsson" <
> [hidden email]>
> > a écrit :
> >
> >> Interesting, I went the opposite way, from JMS to @Asynchronous.
> >>
> >> I began using JMS for asynchronous requests that were required
> >> to be transactional and reliable. This worked great during
> >> initial development, first with OpenMQ in GlassFish and then
> >> with ActiveMQ in OpenEJB/TomEE. But when I started testing
> >> ActiveMQ failover configurations under heavy loads, I started
> >> getting lost messages and hung JMS connections.
> >>
> >> So after struggling for a while I ended up rolling my own
> >> persistent queue in SQL, and used @Asynchronous for the request
> >> dispatch. That turned out to solve all of my problems, and the
> >> overall configuration also become notably simpler.
> >>
> >> --
> >> Bjorn Danielsson
> >> Cuspy Code AB
> >>
> >>
> >> "Howard W. Smith, Jr." <[hidden email]> wrote:
> >> > On Sat, Mar 23, 2013 at 5:55 PM, Romain Manni-Bucau
> >> > <[hidden email]>wrote:
> >> >
> >> >> just to be sure: @Schedule != @Asynchronous
> >> >>
> >> >>
> >> > True/understood. hahaha!
> >> >
> >> > My point is this... since i had issues using @Asynchronous, it is hard
> >> > going back to @Asynchronous since i'm loving AMQ/JMS. :)
> >> >
> >> > I think I heard you and/or others say that JMS is old technology
> (java ee
> >> > 5), and I know @Asynchronous is java ee 6, so i trust @asynchronous
> can
> >> do
> >> > the job, but i even heard that @asynchronous is not good to use in
> JSF or
> >> > servlet (request-based) apps.
> >>
>
Reply | Threaded
Open this post in threaded view
|

Re: Question on MDB processing

Romain Manni-Bucau
"are you replicating database via tomee/tomcat session replication?"
doesn't mean anything IMO...look MySQL cluster for such a thing, that's no
more the app server job (or it shouldn't be)

*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*



2013/3/24 Howard W. Smith, Jr. <[hidden email]>

> Bjorn, for some time now, i've been wondering how to have 2 separate TomEE
> servers (for failover) and one copy of your database per  TomEE? are you
> replicating database via tomee/tomcat session replication?
>
> sometime ago, i searched google about this, but honestly... i don't
> understand how to replicate database in cluster environment. i am using
> eclipselink as jpa provider, and i think i saw something related to
> cluster/replication via eclipselink. i couldn't find any blogs or anything
> out there talking about this subject much. :(
>
>
> On Sun, Mar 24, 2013 at 1:35 PM, Bjorn Danielsson <
> [hidden email]> wrote:
>
> > Well, I still have networking between my two (for failover)
> > TomEE servers and the SQL service that holds the queue and
> > commits the transactions. But I eliminated a middle-man :)
> >
> > --
> > Bjorn Danielsson
> > Cuspy Code AB
> >
> >
> > Romain Manni-Bucau <[hidden email]> wrote:
> > > Yes, you squeezed the network layer, you avoided network problems ;)
> > > Le 24 mars 2013 18:12, "Bjorn Danielsson" <
> > [hidden email]>
> > > a écrit :
> > >
> > >> Interesting, I went the opposite way, from JMS to @Asynchronous.
> > >>
> > >> I began using JMS for asynchronous requests that were required
> > >> to be transactional and reliable. This worked great during
> > >> initial development, first with OpenMQ in GlassFish and then
> > >> with ActiveMQ in OpenEJB/TomEE. But when I started testing
> > >> ActiveMQ failover configurations under heavy loads, I started
> > >> getting lost messages and hung JMS connections.
> > >>
> > >> So after struggling for a while I ended up rolling my own
> > >> persistent queue in SQL, and used @Asynchronous for the request
> > >> dispatch. That turned out to solve all of my problems, and the
> > >> overall configuration also become notably simpler.
> > >>
> > >> --
> > >> Bjorn Danielsson
> > >> Cuspy Code AB
> > >>
> > >>
> > >> "Howard W. Smith, Jr." <[hidden email]> wrote:
> > >> > On Sat, Mar 23, 2013 at 5:55 PM, Romain Manni-Bucau
> > >> > <[hidden email]>wrote:
> > >> >
> > >> >> just to be sure: @Schedule != @Asynchronous
> > >> >>
> > >> >>
> > >> > True/understood. hahaha!
> > >> >
> > >> > My point is this... since i had issues using @Asynchronous, it is
> hard
> > >> > going back to @Asynchronous since i'm loving AMQ/JMS. :)
> > >> >
> > >> > I think I heard you and/or others say that JMS is old technology
> > (java ee
> > >> > 5), and I know @Asynchronous is java ee 6, so i trust @asynchronous
> > can
> > >> do
> > >> > the job, but i even heard that @asynchronous is not good to use in
> > JSF or
> > >> > servlet (request-based) apps.
> > >>
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Question on MDB processing

smithh032772
"are you replicating database via tomee/tomcat session replication?"


> that's no more the app server job (or it shouldn't be)
>
>
please explain.
12