You can also use from(“mlll://8888”) and camel-mllp will create the 
InetSocketAddress without specific a host, so it should work as well.

HTH


> On Oct 5, 2018, at 6:20 AM, John F. Berry <[email protected]> wrote:
> 
> Thanks Stephan!  
> For not knowing my question, you answered it perfectly.  I knew localhost and 
> 127.0.0.1 is a logical loopback, but I did not realize the significance 
> 0.0.0.0.. I've seen that, but thought people used it as a placeholder as to 
> not put in a "real" IP.  I did not realize it was a real thing.  That works 
> wonderful.
> 
> On Friday, October 5, 2018, 2:07:46 AM EDT, Siano, Stephan 
> <[email protected]> wrote: 
> Hi,
> 
> I am not sure if I get your question. If you bind the listening socket to 
> localhost:8888 it is bound to the (IPv4) loopback interface, which is of 
> course only reachable from the local host. 
> 
> If you want to bind to all interfaces, you would have to use 
> mllp:0.0.0.0:8888 (which would mean all IPv4 interfaces, though I have no 
> clue if this works with MLLP).
> 
> If you use HOSTNAME, you will bind to the externally reachable remote 
> interface, which is reachable externally.
> 
> Best regards
> Stephan
> 
> -----Original Message-----
> From: John F. Berry <[email protected]> 
> Sent: Donnerstag, 4. Oktober 2018 15:55
> To: Users <[email protected]>
> Subject: Consuming MLLP uri cannot be "seen" with localhost or 127.0.0.1 from 
> external
> 
> I have an external system sending HL7 messages via MLLP (I could use netty) 
> and if I specify localhost or 127.0.0.1 the external system says the port is 
> not open.  If I use hostname, it works fine.
> 
> from("mllp://HOSTNAME:8888")         This works
> from("mllp://localhost:8888")  this doesn't (for the external system anyway)
> 
> Is this a limitation of the mllp package I'm using, or just "nature of the 
> beast" camel behavior.
> I'd like not to have to specify hostname explicitly so I can run this on any 
> machine I execute it on.
> I assume it's exposing the port with the explicit hostname, since it has to 
> resolve it "further out" on the networking level than localhost?
> 
> Thanks!

Reply via email to