Hi all
So MDBs were the solution.
Just had to tweak some things
My "worker" now is a MDB
@MessageDriven(activationConfig = {
@ActivationConfigProperty(propertyName = "destinationType",
propertyValue = "javax.jms.Queue"),
@ActivationConfigProperty(propertyName = "destination",
propertyValue = "FooQueue"),
@ActivationConfigProperty(propertyName = "acknowledgeMode",
propertyValue = "Auto-acknowledge") })
public class JmsWorkerEJB implements MessageListener {...}
I could not find where to define the name of the
ActiveMQResourceAdapter in the MDB (it is here right?
http://activemq.apache.org/activation-spec-properties.html), so I had
to rename my resource to the "default name"
<!-- <Resource id="MyJmsResourceAdapter"
type="ActiveMQResourceAdapter"> -->
<Resource id="Default JMS Resource Adapter"
type="ActiveMQResourceAdapter">
BrokerXmlConfig = broker:(tcp://localhost:61616)?persistent=true
ServerUrl = tcp://localhost:61616
DataSource = MyJmsDataSource
maximumRedeliveries = -1
</Resource>
<Resource id="MyJmsConnectionFactory"
type="javax.jms.ConnectionFactory">
ResourceAdapter = Default\ JMS\ Resource\ Adapter
</Resource>
<Container id="foo2" type="MESSAGE">
InstanceLimit 5
</Container>
And now I have 5 nice MDBs consuming simultaneously from the same JMS
and working as expected. :-)
I don't bother with the name of the resource, since I don't use for
anything else and it seems to be working now, but if anyone knows how
to do this in the right way, I'd appreciate to know. :-)
(actually I've posted other questios today that are more important than this)
thanks again
Leo
On Tue, Jul 9, 2013 at 4:12 PM, Leonardo K. Shikida <[email protected]> wrote:
> Howard and Romain,
>
> thanks for the help and advices
>
> I think it will work here if I use MDBs to consume the queue. Probably
> it's better then trying to trigger scheduled beans to do the same.
>
> And I can control the pool size using
>
> <Container id="foo" type="MESSAGE">
> InstanceLimit 5
> </Container>
>
> TIA
>
> Leo
>
>
> On Tue, Jul 9, 2013 at 3:55 PM, Romain Manni-Bucau
> <[email protected]> wrote:
>> Just some notes: stateless beans are thread safe not singleton beans +
>> postconstruct is fine on stateless but will be called for all instances in
>> the pool
>> Le 9 juil. 2013 20:26, "Howard W. Smith, Jr." <[email protected]> a
>> écrit :
>>
>>> Leonardo, you may want to revisit Java EE 6 tutorial. almost 2 years ago
>>> (summer 2011), before I began coding Java EE, I studied Java EE 6 tutorial,
>>> and since I been doing (minimal) Java EE 6 ever since, by looking at your
>>> code, I will respond as follows (based on my learning):
>>>
>>> 1. I would never add @Startup on @Stateless, even though I've seen others
>>> add @startup on@Singleton, and from what I thought/learned/read,
>>> @Singleton
>>> is @Stateless, but I could be wrong. :)
>>>
>>> 2. I would never add or 'assume' that @PostConstruct should be added to
>>> @Stateless. per my Java EE 6 tutorial learning-and-understanding of
>>> @PostConstruct, I should only add @PostConstruct on managed beans
>>> (@RequestScoped, @SessionScoped, etc...)
>>>
>>> my 'two' cents...
>>>
>>> Oh, I have learned from TomEE committers that I can/should use @Singleton
>>> @Lock(Read or Write), and I can add @Schedule methods to @Singleton
>>> bean(s). I am doing (all of) this in my app, using TomEE 1.6.0, and I am
>>> very satisfied with the performance of the app. But I am not using
>>> @Startup; i have an @ApplicationScoped CDI bean that is global to entire
>>> app, all sessions, the @Singleton beans, etc... when TomEE starts my app,
>>> @ApplicationScoped bean will be instantiated and I can add @PostConstruct
>>> to this CDI @ApplicationScoped bean to do whatever I want to do when my app
>>> 'starts'...so why do I need @Startup? don't need it and I don't use it.
>>>
>>>
>>>
>>>
>>> On Tue, Jul 9, 2013 at 1:19 PM, Leonardo K. Shikida <[email protected]
>>> >wrote:
>>>
>>> > learning something new everyday ;-)
>>> >
>>> > []
>>> >
>>> > Leo
>>> >
>>> >
>>> > On Tue, Jul 9, 2013 at 2:06 PM, Romain Manni-Bucau
>>> > <[email protected]> wrote:
>>> > > @Startup on stateless doesnt mean anything in the spec IIRC ;)
>>> > > Le 9 juil. 2013 19:04, "Leonardo K. Shikida" <[email protected]> a
>>> > écrit :
>>> > >
>>> > >> No, it's a regular @Stateless
>>> > >>
>>> > >> @Stateless
>>> > >> @Startup
>>> > >> public class JmsWorkerEJB {...}
>>> > >>
>>> > >> It has a method annotated with @Schedule that reads from a JMS queue.
>>> > >>
>>> > >> In the worst case, since @PostConstruct is being called, I could
>>> > >> schedule from there instead, but does not seems an elegant way to deal
>>> > >> with that :-)
>>> > >>
>>> > >> []
>>> > >>
>>> > >> Leo
>>> > >>
>>> > >>
>>> > >> On Tue, Jul 9, 2013 at 1:56 PM, Romain Manni-Bucau
>>> > >> <[email protected]> wrote:
>>> > >> > Found in code this time ;)
>>> > >> >
>>> > >> > Is your ejb a singleton? Did you set @lock(read)?
>>> > >> >
>>> > >> > Working thread can be done with @Asynchronous in javaee 6
>>> > >> > Le 9 juil. 2013 18:52, "Leonardo K. Shikida" <[email protected]> a
>>> > >> écrit :
>>> > >> >
>>> > >> >> MinSize does instantiate these :-)
>>> > >> >>
>>> > >> >> Where did you find this parameter?
>>> > >> >>
>>> > >> >> But the method annotated with @Schedule is run only for one
>>> instance
>>> > >> >> at a time. I thought it should run for all of them.
>>> > >> >>
>>> > >> >> How people usually implement the concept of working threads in EJB?
>>> > >> >> Maybe I am trying to do this in the wrong way.
>>> > >> >>
>>> > >> >> TIA
>>> > >> >>
>>> > >> >> Leo
>>> > >> >>
>>> > >> >>
>>> > >> >> On Tue, Jul 9, 2013 at 1:37 PM, Romain Manni-Bucau
>>> > >> >> <[email protected]> wrote:
>>> > >> >> > Did you try MinSize?
>>> > >> >> > Le 9 juil. 2013 18:16, "Leonardo K. Shikida" <[email protected]>
>>> a
>>> > >> >> écrit :
>>> > >> >> >
>>> > >> >> >> Hi Romain
>>> > >> >> >>
>>> > >> >> >> I've added to tomee.xml
>>> > >> >> >>
>>> > >> >> >> <Container id="foo" type="STATELESS">
>>> > >> >> >> PoolSize=10
>>> > >> >> >> </Container>
>>> > >> >> >>
>>> > >> >> >> but it didn't worked as I was expecting.
>>> > >> >> >>
>>> > >> >> >> I thought it would instantiate 10 instances.
>>> > >> >> >>
>>> > >> >> >> I've also added a sysout in the
>>> > >> >> >>
>>> > >> >> >> @PostConstruct
>>> > >> >> >> public void init() {
>>> > >> >> >> System.out.println("Hello "+this);
>>> > >> >> >>
>>> > >> >> >> I thought I'd have 10 lines in the first service, but there was
>>> > only
>>> > >> >> one.
>>> > >> >> >>
>>> > >> >> >> Do I have to set somewhere (somehow) that my bean is using this
>>> > >> >> >> container or tomee assumes it's the default configuration for
>>> all
>>> > >> >> >> stateless beans?
>>> > >> >> >>
>>> > >> >> >> TIA
>>> > >> >> >>
>>> > >> >> >> Leo
>>> > >> >> >>
>>> > >> >> >>
>>> > >> >> >> On Tue, Jul 9, 2013 at 12:29 PM, Romain Manni-Bucau
>>> > >> >> >> <[email protected]> wrote:
>>> > >> >> >> > Hi
>>> > >> >> >> >
>>> > >> >> >> > The basic conf is here
>>> > >> >> >> http://tomee.apache.org/containers-and-resources.html
>>> > >> >> >> >
>>> > >> >> >> > You can set PoolSize (MaxSize) but MinSize too
>>> > >> >> >> > Le 9 juil. 2013 14:45, "Leonardo K. Shikida" <
>>> [email protected]>
>>> > a
>>> > >> >> >> écrit :
>>> > >> >> >> >
>>> > >> >> >> >> Hi
>>> > >> >> >> >>
>>> > >> >> >> >> I am using a stateless bean to consume from a jms queue
>>> > >> periodically
>>> > >> >> >> >> (@Schedule). It's started with the container (@Startup). Is
>>> > there
>>> > >> any
>>> > >> >> >> >> way to configure somewhere the initial number of instances
>>> for
>>> > >> this
>>> > >> >> >> >> specific bean?
>>> > >> >> >> >>
>>> > >> >> >> >> TIA
>>> > >> >> >> >>
>>> > >> >> >> >> Leo
>>> > >> >> >> >>
>>> > >> >> >>
>>> > >> >>
>>> > >>
>>> >
>>>
