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 with a simple junit test case and open an issue, it
would be a good start point for further investigation.

Is the the behavior the same when u use the default store cursor? My
guess is that it is but just incase.

On 24 February 2012 00:47, mserrano <mar...@attivio.com> wrote:
> version 5.5.1
> broker cfg:  memory: 256M, Store:10g, Swap/tmp:10g, persistence=true,
> producerFlowControl=true
>
> I'm using the  http://activemq.apache.org/message-cursors.html
> fileQueueCursor  destination policy for a queue.  It appears to properly
> page in messages in the cursor without blocking when it gets to 70% memory
> use.  The queue is being read by a transacted session consumer which is
> keeping open the transaction for a many messages (>10k).  The messages
> themselves are large (800k or so).  What I see is that the Queue
> pagedInMessages data structure will grow without bound and contains a
> reference to every message dispatched to the consumer.   Eventually the
> broker will run out of memory.
>
> Producer flow control does not get triggered (but if it did my transaction
> would not be able to get all the messages it needs and would never
> complete).
>
> Is it just not possible to use ActiveMQ in this way?  What I mean by this is
> that I'd like the total size of the number of messages * the size of the
> messages of an open transaction to be bounded by the disk store limits not
> by memory limits.  Since the messages are persisted, it seems like this
> should be possible.
>
> Any suggestions for what I should do differently?  Would the
> connection.setTransactedIndividualAck setting in 5.6 help here?
>
> I'm happy to work on fixes/tests for this but need some guidance.
>
>
> --
> View this message in context: 
> http://activemq.2283324.n4.nabble.com/out-of-memory-using-producer-flow-control-and-fileQueueCursor-tp4415752p4415752.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.



-- 
http://fusesource.com
http://blog.garytully.com

Reply via email to