Re: [Solved] Consuming MLLP uri cannot be "seen" with localhost or 127.0.0.1 from external
You can also use from(“mlll://8888”) and camel-mllp will create the InetSocketAddress without specific a host, so it should work as well.
> On Oct 5, 2018, at 6:20 AM, John F. Berry <bohnjerry@xxxxxxxxx.INVALID> 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 <stephan.siano@xxxxxxx> wrote:
> 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
> -----Original Message-----
> From: John F. Berry <bohnjerry@xxxxxxxxx.INVALID>
> Sent: Donnerstag, 4. Oktober 2018 15:55
> To: Users <users@xxxxxxxxxxxxxxxx>
> 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?