it takes longer because the messages are persisted to disk

there are extra overheads with paging

There were some improvements on the latest versions. Why don't you try the version that comes with AS7? you could just download the latest AS7 and try it out as it was a standalone or you could download the branch and build it yourself.

There were some improvements as when we sync and making it more asynchronous. Did you get a chance to test the latest version?

How are you commiting your data? How are you producing? How are you consuming? (General observations that will help on any message system)

Hi,

I have a question that relates with this one. Besides the documentation (http://docs.jboss.org/hornetq/2.2.5.Final/user-manual/en/html_single/index.html#paging) I didn’t find any other source of information where I could find an answer.

When in Paging Mode, which means that “max-size-bytes” has been reached, what happens to the new messages that are delivered in that destination? Are they paged one by one? I would expect that newest “page-size-bytes” messages would be paged in blocks, and the old ones (who are the first to be delivered) to be kept in memory. This implies that “page-size-bytes” should be less or equal to “max-size-bytes”.

Thanks for the help,

   Luís M. Costa

That is correct...

if you actually size page-size-bytes > max-size that would be a configuration error (you would immediately starve the memory if the page-size > max-page-size whenever you added stuff to the memory).

Paging is a overflow of the memory, so the first messages are kept in memory.

Hi Clebert!

Thank you for your response, but... what is correct?

My assumption that 1) the newest "page-size-bytes" messages are stored in blocks or, instead, 2) they are paged one by one on receive?

Thanks,

   Luís M. Costa

I have exactly the same timeout of about 3 seconds when messages are paged out.

I tested with 2.2.14 Final, using the core API to generate the messages and also the core API to consume the messages. Consuming isn't a issue.

With my testing I found that the buffers which is paged out ist quite small (385 messages which look like "Messsage: 1234").

Every time this Buffer is wirtten to disk the delay occurs. I checked it with wireshark and the delay is also there visible.

Regards

Stefan

There's a timed buffer writing to the pages. If you have a single producer, you need to wait the conclusion of that write.. it should scale when you have more than one producer... and you can configure the timed buffer.

Ok I have to wait until the write has finished. But why does this take 3 seconds. It can't be a write (IO) bound problem. Something else ist waiting here.

The only place I find timed buffer in the docs ist the journal-buffer-timeout and journal-buffer-size and here a max of 490k are written many hundred times a second!

Any idea where the paging buffer is configured?