Akka and JMS

[Shinhung]

I'm rather short on wit on how to interact between mdb and actors.
What I would like to do is for each actor to send a notification
message to the mdb upon finishing its task. But I have no idea how to
handle its connection pooling. I set the actor dispatcher's
maxPoolSize to 128 while the mdb has an endpointPoolMaxSize of 32.
I would get either errors:
WARNING: RAR7004 : MDB deployment is still happening. Cannot create
end point now.
or
com.sun.messaging.jms.JMSException: MQRA:DCF:allocation
failure:createConnection:Error in allocating a connection. Cause: In-
use connections equal max-pool-size and expired max-wait-time. Cannot
allocate more connections.

I don't think setting endpointPoolMaxSize to match the number of
simultaneous connections it may open is a cure all. Any suggestions?

[√iktor Ҡlang]

Hi Shinhung,

I'm afraid I don't understand the question.
Could you elaborate?

Cheers,

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

--
Viktor Klang,
Director of Research and Development
Scalable Solutions

Code:   github.com/viktorklang
Follow: twitter.com/viktorklang
Read:   klangism.tumblr.com

[Shinhung]

Hmm wait I'll check out Camel.

[Alex Cruise]

On Tue, Apr 12, 2011 at 4:26 AM, Shinhung <sanjaya...@gmail.com> wrote:

Hmm wait I'll check out Camel.

Hi there,

Just a quick note, I switched my project's remote communications to Akka-Camel-ActiveMQ and it's been rock solid.  No doubt a large part of that stability is thanks to refactoring everything that's remote to exclusively use one-way messages, not just changing the transport layer.  Of course, I'm now dragging a much bigger raft of dependencies, can't win. :)

-0xe1a

[Shinhung]

Well, I would like to use Actors to each make an HTTP request against
an sms gateway. The return is a transaction ID that I need to
register somewhere in the application, in order that it could match
which delivery status is for which transaction ID. The registry is an
MDB.

I haven't much learnt about MDB or Actors, i.e. new to everything
concurrent and parallel, really but from what little I've experienced,
if each Actor creates a connection to the MDB to send a message (which
contains the transaction ID), the number of connections would grow to
be as many as the number of Actors as maxPoolSize set (128, I set it
so), while the number of maximum connections to the MDB is only 32 by
default. I still haven't figured out a way to reuse the connection
and being able to close the connection (citing JEE Tutorial: Failure
to close a connection can cause resources not to be released by the
JMS provider. Closing a connection also closes its sessions and their
message producers and message consumers."), or if it's even good
practice since it might induce locking. It's just like what Alex is
doing, I would also like exclusive use of one-way messages for this
part of the application, except I have yet to check out Camel.

> Scalable Solutions <http://www.scalablesolutions.se>

[schoefts]

Hi Shinhung,

not sure I got you right, but here's how I've been working with akka
and JMS in the past:

1 - ad JMS connection)
If you use akka-camel, you'll have to rely on camel when it comes to
JMS connection management.
I.e. you register a new JMSComponent under a specific name (e.g.
"fooqueue") in akka-camel.
A JMSComponent needs a connectionfactory for interacting with a JMS
broker/queue.
The connectionfactory, however, requires all the connection
parameters, such as broker URL, user, password, queue-name, etc.

Having done that, all your actors can transparently use the camel
endpoint prefix "fooqueue:" to send send messages to that specific
queue.
The connection management (open/close) is transparent to your actor.
Slightly modified example from the akka-camel docs:
class MyActor extends Actor with Consumer {
def endpointUri = "fooqueue:tcp://localhost:6200?textline=true"

def receive = {
case msg: Message => { /* ... */}
case _ => { /* ... */}
}
}

2 - ad connection pooling)
As far as I know, camel/akka-camel does not natively support
connection pooling.
If you want to achieve that you'll have to register a pooling
ConnectionFactory.
If your JMS broker does not provide pooling capabilities, you can use
Spring's CachingConnectionFactory. - Don't worry you won't need an
application context and whatnot.

3 - ad no of actors vs no of connections)
1 actor can only process 1 message at a time.
Therefore, you won't make good use of a pool if you have only 1 actor.
However, if you use multiple akka-camel actors for parallel processing
and each of them uses the same queue (aka camel endpoint), they will
share the underlying connection.
If you use a pooled connection factory (see 1), they'll share the
connection pool.

I hope this helps!
cheers,
-Tom

[Shinhung]

Hi Tom,

That surely helps a lot. Thanks!

[schoefts]

Ups - just noticed I messed up a couple of things in this example:

1) You register the JMSComponent under a certain name, BUT you don't
specify the queue name yet.
Hence the camel prefix should not be named "fooqueue" but rather
"foobroker".

2) The queue/topic needs to be specified in the Camel connection
string.
Examples: "foobroker:queue:fooqueue", "foobroker:topic:footopic"

Sorry for the mixup.

cheers,
-Tom