Hi, Justin. My environment:

java version "1.8.0_66"

Java(TM) SE Runtime Environment (build 1.8.0_66-b17)

Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)

Linux sender5.host11.com 3.13.0-45-generic #74-Ubuntu SMP Tue Jan 13 19:36:28 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Distributor ID: Ubuntu

Description: Ubuntu 14.04.3 LTS

Release: 14.04

Codename: trusty

Yes, there is one file with size 0.

How was it created? Also, can I just kill it?

Getting a test case would be tough,  as we have this embedded into our app.

One other thing is: we do not want large messages. our biggest messages are just over 100k. So, we configured a minimum large message size to be 250000, but large message files are still created.

Sorry for so many questions, and thanks for advice!

Here is what we did:

1. Reduced the sized of messages being sent into broker (50% of what we sent before)

2. Deleted all large messages from largemessages directory (backed them up)

3. Restarted the app and got the same exception:

java.lang.UnsupportedOperationException

  at java.nio.ByteBuffer.array(ByteBuffer.java:994)

  at org.hornetq.core.server.impl.ServerConsumerImpl$LargeMessageDeliverer.deliver(ServerConsumerImpl.java:1090)

  at org.hornetq.core.server.impl.ServerConsumerImpl$2.run(ServerConsumerImpl.java:969)

  at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:104)

  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

  at java.lang.Thread.run(Thread.java:745)

Now, the broker created 11 files with 0 size

drwxrwxr-x 2 pigeon pigeon 4096 Dec 30 14:23 ./

drwxr-xr-x 8 pigeon pigeon 4096 Dec 30 14:21 ../

-rw-rw-r-- 1 pigeon pigeon    0 Dec 30 14:22 12896597601.msg

-rw-rw-r-- 1 pigeon pigeon    0 Dec 30 14:22 19338070485.msg

-rw-rw-r-- 1 pigeon pigeon    0 Dec 30 14:22 19338070491.msg

-rw-rw-r-- 1 pigeon pigeon    0 Dec 30 14:22 19338070496.msg

-rw-rw-r-- 1 pigeon pigeon    0 Dec 30 14:22 19338070499.msg

-rw-rw-r-- 1 pigeon pigeon    0 Dec 30 14:22 19338070503.msg

-rw-rw-r-- 1 pigeon pigeon    0 Dec 30 14:22 19338070506.msg

-rw-rw-r-- 1 pigeon pigeon    0 Dec 30 14:22 19338070522.msg

-rw-rw-r-- 1 pigeon pigeon    0 Dec 30 14:22 19338070525.msg

-rw-rw-r-- 1 pigeon pigeon    0 Dec 30 14:23 19338070531.msg

-rw-rw-r-- 1 pigeon pigeon    0 Dec 30 14:22 9230422.msg

Also, it shows that QueueControl#countMessages(null)); returns more than 18k messages in the queue, but they are not delivered. They are just sitting there.

We set the min size of large messages programmatically:

ConnectionFactoryConfiguration cfConfig = ....;

cfConfig.setMinLargeMessageSize(250000);

Appreciate helping!

latest update:

I re-created entire directory where HornetQ stores any data, and restarted the process. It is working smoothly now. Apparently some data file somewhere had a poison pill.

I can re-sent all messages again, so no data loss. I "resolved" the problem, but still do not know what caused it and how to avoid in future,

I solved my immediate problem, but if you want to recreate this condition, and improve the product, I can make my data directory available to you.

All you need to do is point to this directory and watch it fail.

Let me know -

tx

I was unaware of this. Is Redhat dropping HornetQ? If so, I can certainly switch to Artemis. What is the roadmap for  messaging under Redhat?

tx

Thanks for the follow up! We are looking to integrate Artemis now.