2

I have a number of MDBs running on Glassfish 3.1.2.2. Due to the nature of work on one of the MDBs I need to make it single threaded. I looked at the Tuning Guide, and while setting the maximum pool size to 1 does resolve the problem, it also means all the other MDBs are single threaded. What I'd really like to do achieve is for the specific MDB to be single threaded, whilst allowing the others to be multi-threaded.

M21B8
  • 1,867
  • 10
  • 20

1 Answers1

3

That's easy to achieve via the glassfish-ejb-jar.xml deployment descriptor:

<glassfish-ejb-jar>
  <enterprise-beans>
    <ejb>
      <ejb-name>YourMDB</ejb-name>
      <bean-pool>
        <resize-quantity>1</resize-quantity>
        <max-pool-size>1</max-pool-size>
        <steady-pool-size>1</steady-pool-size>
      </bean-pool>
    </ejb>
  </enterprise-beans>
</glassfish-ejb-jar>

The above section will limit the number of processing beans to strictly 1, regardless of what the global poolsize says. That way you can easily finetune the system setup.

fvu
  • 32,488
  • 6
  • 61
  • 79
  • bingo, just what I needed. Thanks – M21B8 Dec 09 '13 at 15:27
  • But be aware of: _Setting a small `max-pool-size` can cause excessive object destruction (and as a result excessive object creation) as instances are destroyed from the pool if the current pool size exceeds `max-pool-size`._ [performance-tuning-guide](https://glassfish.java.net/docs/4.0/performance-tuning-guide.pdf) – dedek Oct 04 '14 at 19:49
  • @dedek yeah I think I've also seen mdb's exhibit that behavior, but to get the behavior OP wants (process messages serially), setting `max-pool-size` to 1 is the only think you can do... – fvu Oct 04 '14 at 21:32
  • @fvu: I had to delegate the processing to other -really singleton- bean because this behavior was very painful in my case. I wish `max-pool-size` was a really strict maximum, but there is probably some reason for this behavior ... does anybody know? – dedek Oct 05 '14 at 14:11
  • @dedek did you observe this overshooting of max-pool-size on MDB's or on session beans? I haven't seen it on MDBs yet - what I have seen with `max-pool-size` is beans that get created, service exactly one message, and then get destroyed even long before the idle time runs out. – fvu Oct 05 '14 at 14:49
  • @fvu: I'm not sure. I would have to check it more carefully. Maybe it was my mistake. I also was not aware of the `pool-idle-timeout-in-seconds` (10 minutes by default?). I will let know if things get clearer. Thank you for your replies. – dedek Oct 07 '14 at 14:21
  • @fvu I don't think this gets you anything, or, at most, it's marginal. I believe that the server will process the messages sequentially as they're received, so there's no gain there. I think you're trying to address the problem that the messages might **arrive** out of order. You'd have to look at timestamps, etc...which I would suggest is counter-productive. – Thufir Mar 05 '15 at 12:28
  • @Thufir indeed, messages will be processed in the order they are received in, but there can be a HUGE difference between having one thread treating them or multiple threads. It depends on the application, but if e.g the calculation done with data from one message depends on previous calculations, the difference will be all but marginal - often the difference will be as dramatic as usable results vs nonsense. – fvu Mar 05 '15 at 12:43
  • @fvu yes..., but we're talking about different things. What's your guarantee that data1 arrived before data2? It probably, and surely was the case, that data1 was **sent** first, but it might have been **received** after data2. Meaning that processing them sequentially is pointless. Since data2 arrived first, it gets processed first -- which surely wasn't the intent. Right? – Thufir Mar 05 '15 at 12:55
  • @Thufir [The JMS spec does](http://download.oracle.com/otndocs/jcp/7195-jms-1.1-fr-spec-oth-JSpec/), within certain well described limits - see chapter 4.4.10. My answer is valid within the same well-described limits. – fvu Mar 05 '15 at 13:42