It seems over the years that an understanding existed in client/server HL7 interfaces that one client sends one message at a time to one port. Any more and you're asking for trouble. We moved an interface I have referenced here before recently off of our interface engine to a direct point to point with Camel. What we discovered is that the sending system creates new work instances based on outbound events, and that some of these can occur simultaneously. mllp and/or the general Camel from/to context does not like this.. I get warnings about the message being rejected due to only having one consumer.. which normally I would agree with how it should work. The interface engine, however, seems to be able to accommodate this.. all except for overly huge messages. This interface carries a base64 encoded pdf if one HL7 field that I decode and place on a file system. Get a 30 or 60 page pdf base64 encoded and you get quite the payload.. thus the need to skip the interface engine, even though it did serialize my traffic for me.
I attempted to not process, but to dump the message into a queue, thinking that the extra "conversation" and subsequent WARN message from Camel about max consumers was from me delaying the ACK while I process.. but later I put it back, since it occured to me that I should not begin receiving another message until I have ACK/NAK'ed the current message... or we've timed out. Neither was the case. So my long winded history is to ask.. Can I/Should I attempt to allow multiple consumers, and how I might accomplish this in camel. This particular situation, unlike normal HL7.. will not have a problem should arrival order of messages not be completely linear. Each event is completely unrelated to the next, etc. I attempted to simply replace mllp with netty and mina.. figuring that perhaps those might have better handling for this situation, but neither like the big messages and give me excessive frame errors. I have, in an additional issue, exceeded my JVM heap size with some big messages.. I'm attempting to handle that on the JVM side but figured I'd mention it to express the massive size of some of these messages. So if there's an idea of running a "from.. to.. javaq" and process later.. I need to accommodate that in the queue I build as well. Thanks all!
