I'm pretty sure this is doable but the question is, is this a logical setup and in what cases would it make sense to do it?

Yes, it's logical.  It makes sense in a use-case like yours.

Has anyone seen this type of setup before and have some insight on the best way to maintain a separate HornetQ container and what would justify this type of setup?

Having a dedicated messaging server is common.  It doesn't require any special maintenance.  There are lots of justifications for having a dedicated messaging server.  Your use-case is one such justification.

My other concern is then how to transfer all that message data to the app servers that will consume it. Seems like we might need another custom component to handle that. Any suggestions?

There's a few ways you could do this:

• Simply copy your current HornetQ configuration and data (in the server's "data" directory) to the dedicated server while the servers are shut-down.
• Use the XML export/import utility that ships with HornetQ.
• Create bridges to move messages from the existing queues to the queues on the dedicated server.

I think you might have misunderstood my last question as I'm not sure the first two options would solve it (unless I'm missing something). What I'm asking is, in a live, running "hornetq server" that is actively receiving messages, how would I allow that message data to be consumed in real-time by my application containers? I want my application to continuously consume messages that are received but only host my hornetq server in its own dedicated container.

Yes, I believe I misunderstood your question.  I thought you were asking how you could migrate your existing message data to your new, dedicated messaging server.

If you want your application on a remote server to consume messages from your messaging server then you simply need to point your application to the remote messaging server rather than the local one.

I believe a bridge would solve this and allow me to create only the necessary queues for each application in its own container. The bridge would effectively serve as a filter so only the messages that are pertinent to each app will be received in that container. Is that what you were suggesting?

My suggestion was made under the aforementioned (and incorrect) assumption that you wanted to migrate your data from one server to another.

...if I wanted to remove hornetq altogether from those other app containers, is there a solution that allows me to not have any hornetq presence in those other containers?

Yes.  However, the integration between HornetQ and the application server provides some advantages that you might not want to give up - namely the pooled-connection-factory which could boost performance considerably depending on how your application is written.

Can I create some sort of bridge or remote call to retrieve messages from my hornetq server without having any queues defined in each of my app containers?

There's no need to create any bridges.  You can simply point your clients directly to the remote messaging server or use a local pooled-connection-factory which is, in turn, pointing to the remote messaging server.  Which you choose will depend on how your application is written, what it's doing, and your performance requirements.