This BZ is designed to track the resolution of JIRA 5924 from upstream to ensure it makes it into the MRG product. See the upstream issue for its full description. [0]: https://issues.apache.org/jira/browse/QPID-5924
Fixed in r.1614665 [https://svn.apache.org/r1614665] See upstream QPID-5924 (link above) for comments.
The number of queues you may be able to create may vary from system to system depending on the version of RHEL and the available hardware resources - I am not familiar with exactly what happens here. IFAIR, the default max per user is 1024 file handles, but this can be extended by the root user. Before the fix, the linearstore recovery was using 2 file handles per queue - one for normal write use after recovery and the other used for reading the contents of the file. After recovery was complete, all of the read file handles were closed together, and only one file handle per queue remained open. It should be possible to test this behavior as follows: 1. Using a client on another machine, create as many queues as possible until you exhaust the available file handles on the broker. If the default is 1024, then you should be able to create about 1000 queues. It might be a good idea to put at least one message on each queue. At this point, the broker should be using 1 file handle per queue. 2. Stop the broker and then restart it. If the broker is using 2 file handles per queue, it should only be able to recover approx. half the queues (approx. 500) before failing. After the fix, the broker should be able to recover all the queues. As the messages are removed, the file handle for that queue will be opened, but you should be able to remove all messages (or perhaps run out of handles very close the last queue). You can use ulimit to see the number of file handles and change the limit, but this test should not depend on an absolute number of handles being available.
verified on qpid-cpp-0.22-46.x qpid-cpp-0.22-47.i