[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Solved] Consuming MLLP uri cannot be "seen" with localhost or 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 is a logical loopback, but I did not realize the significance 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: 
> 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: (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 <bohnjerry@xxxxxxxxx.INVALID> 
> Sent: Donnerstag, 4. Oktober 2018 15:55
> To: Users <users@xxxxxxxxxxxxxxxx>
> Subject: Consuming MLLP uri cannot be "seen" with localhost or from external
> I have an external system sending HL7 messages via MLLP (I could use netty) and if I specify localhost or 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!