I've found an article which deals with a similar issue (overrive MDB
configuration).
In jboss.xml when deleting from the ** section,
the MDBs connect succesful to ActiveMQ:
I do not know exactly what the impact is deleting this Metric plugin, I will
forward this question to the JBoss mailing li
Greetings all!
I've been trying to connect an MDB (deployed to JBoss EAP 5.1.2) to ActiveMQ
5.5.1, but so far... no luck.
I am using the panacya-mdb-test-1.0.jar example (from
http://activemq.apache.org/jboss-integration.html) and tried to connect to
either an embedded or external ActiveMQ broker
I will look at IndirectMessageReference more closely. The pendingMessages
map does have an IndirectMessageReference for each dispatched message. And
each IndirectMessageReference contains an ActiveMQTextMessage (in my case)
which is the fully realized message.
So the trick is to know when the
When I use the default store cursor, then the system will end up blocking.
This is because the cursor reaches the 70% watermark and stops dispatching
messages to the consumer. This is also not viable for us because then there
is no way to get all the messages to the consumer it need to complete t
On Thu, 2012-02-23 at 19:38 -0800, davidw wrote:
> OH - here's an example of what gets printed to the logs when it works
>
>
>
> and the message that seems to break it
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/JMS-goes-in-sometimes-STOMP-comes-out-bu
Thanks. I am storing only the payload (it was an ObjectMessage).
I was able to resolve the issue by spawning a new thread to create my
singleton instance. I read the following from
http://docs.oracle.com/javaee/5/api/javax/jms/Session:
Once a connection has been started, any session with one or m
>From a fix perspective, have a look at
org.apache.activemq.broker.region.IndirectMessageReference
it seems to be what is needed but I don't think it is currently
utilised to the full or fleshed out.
On 24 February 2012 11:52, Gary Tully wrote:
> That seems to be a reasonable expectation, that t
That seems to be a reasonable expectation, that transaction size is
not limited to available memory.
There was some work on trunk to have an in-memory send transaction
overflow to a temp file but it looks
like the pending massages cursor is a limitation for the receive side.
If you can produce wit
Actually wrote that too soon. They have different purposes:
QueueSize contains the count of the messages in the store that have not yet
been acknowledged as consumed. This persists between broker
restarts/failovers.
EnqueueCount, DispatchCount and DequeueCount are counters that are specific
to th
Thats consistent with something I saw recently. The EnqueCount, DispatchCount
numbers are reset to 0 on broker restart. The QueueSize takes into account
persisted messages that were in the store when the broker started.
I have a config that I can reproduce it with - I'll log it as a bug.
Jakub
Hi Matt,
Yes message groups would do the job, as they guarantee that only one
consumer is responsible for consuming that group. From the docs, they
provide "guarranteed ordering of the processing of related messages across a
single queue".
I can't speak about your consumer code, but storing the e
look at org.apache.activemq.ActiveMQConnection#getResourceManagerId
or org.apache.activemq.ActiveMQConnection#getBrokerName
you can cast your QueueConnection to ActiveMQConnection
On 24 February 2012 06:45, archa wrote:
> The message broker used in my application has the failover protocol used o
12 matches
Mail list logo