Re: [Solved] Consuming MLLP uri cannot be "seen" with localhost or 127.0.0.1 from external
You can also use from(“mlll://”) 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 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
> wrote:
> Hi,
>
> I am not sure if I get your question. If you bind the listening socket to
> localhost: 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: (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
> Sent: Donnerstag, 4. Oktober 2018 15:55
> To: Users
> 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:") This works
> from("mllp://localhost:") 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!
Antwort: RE: Antwort: CXF : setting maxChildElements on endpoint
Hi, I think you are right. But perhaps you can use your own (second) bus for some CXF-Enpoints, with its own configuration file (http://camel.apache.org/cxf.html --> bus, http://cxf.apache.org/docs/configuration-of-the-bus.html). But I have no practical knowledge. Wish you success, perhaps someone else can give you some helpful advices... Björn Von:"Duchaine, David" An: "users@camel.apache.org" Datum: 05.10.2018 12:34 Betreff:RE: Antwort: CXF : setting maxChildElements on endpoint Hi, Won't setting the property on the bus be effective for all endpoints in the Camel context? Reading the doc you reference, it says: Contextual properties which will be applied to all endpoints and clients using this bus Actually, I don't know how Camel manages all the CXF endpoints that are configured in the context. Is there a shared bus for all routes using the CXF component. A bus per route? Thanks, David Diese E-Mail könnte vertrauliche und / oder rechtlich geschützte Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht gestattet. This e-mail may contain confidential and / or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
[Solved] Consuming MLLP uri cannot be "seen" with localhost or 127.0.0.1 from external
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
wrote:
Hi,
I am not sure if I get your question. If you bind the listening socket to
localhost: 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:
(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
Sent: Donnerstag, 4. Oktober 2018 15:55
To: Users
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:") This works
from("mllp://localhost:") 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!
Re: Integration tests with Spring annotations
Hello, yes I have replaced all my beans (+ added a connection factory) in
the configuration context and had to add some constructors in my
routebuilder classes to directly initialize autowired services.
Now Its work fine, thanks ;)
Le jeu. 4 oct. 2018 à 18:28, Valdis Andersons a
écrit :
> Hi Damien,
>
> Sorry for the late response, been a bit busy with Camel and Rabbit routes
> at work.
> Did you get this to work by any chance?
> If not, I think what's missing in your test setup is the @Bean
> declarations in your test context. In the pastebin example you posted I saw
> an empty @Configuration class being passed into the test context. If you
> want you can also pass in the real context from the application, but that
> usually is overkill and not necessary (unless you're doing a full on
> end-to-end integration test, but there are better way to do that).
> Basically your test context needs the @Bean declarations that are used by
> your class under test. So, if your RouteBuilder.class has @Autowired
> dependencies, then you either need to declare @Bean for them in the test
> context or provide a mock for them.
>
> This would be part of my RestTestConfiguration.class:
>
> ...
> @Bean
> public PersonServiceFacade personServiceFacade() {
> return new PersonServiceFacadeImpl();
> }
>
> @Bean
> public RequestContextListener requestContextListener() {
> return new RequestContextListener();
> }
>
> @Bean
> public StubProcessor stubProcessor() {
> return new StubProcessor();
> }
>
> @Bean
> public WebServicesFacade testWebservicesFacade() {
> return new StubWebServicesFacadeImpl();
> }
> ...
>
> And so on...
>
>
> Thanks,
> Valdis
>
> -Original Message-
> From: Damien Nicolas [mailto:dmn.nico...@gmail.com]
> Sent: 02 October 2018 15:47
> To: users@camel.apache.org
> Subject: Re: Integration tests with Spring annotations
>
> My @Autowired are in my "RouteBuilder.class". Plus, I'm using
> JpaRepository (WorkflowRepository is this implementing it).
> I declared my service " WorkflowService" as a bean in my configuration,
> but It is not referenced in the application context of the test..
>
> Le lun. 1 oct. 2018 à 13:04, Valdis Andersons a
> écrit :
>
> > Hi Damien,
> >
> > In your test you need specify the configuration your Camel context is
> > supposed to use. This is how we're setting it up:
> >
> > @Override
> > protected AbstractApplicationContext createApplicationContext() {
> >
> > AbstractApplicationContext applicationContext = new
> > AnnotationConfigApplicationContext(RestTestConfiguration.class,
> > SomeRouteBuilder.class, RepoFactory4Test.class);
> > return applicationContext;
> > }
> >
> > In your case the bean you're looking for - WorkflowRepository, also
> > needs to be specified there. Whether you do it directly like
> > SomeRouteBuilder above or via a @Configuration class like the above
> > RestTestConfiguration and RepoFactory4Test classes is entirely up to
> > you. The Spring's ContextConfiguration class might also work there if
> > you specify the WorkflowRepository configuration on/in it.
> > We keep all the common beans that all tests need in the @Configuration
> > classes and the test specific one's are then passed in directly in
> > each test case.
> > While I'm not 100% certain it's the best or the most correct way of
> > doing things it's been working very reliably so far for us.
> >
> > Regards,
> > Valdis
> >
> > -Original Message-
> > From: Damien Nicolas [mailto:dmn.nico...@gmail.com]
> > Sent: 01 October 2018 10:20
> > To: users@camel.apache.org
> > Subject: Re: Integration tests with Spring annotations
> >
> > Thanks for you reply!
> >
> > Here its a sample of my test configuration:
> > https://scanmail.trustwave.com/?c=6600=hYWz26Ot-ae0hW1VlFM7GqsIjY4SG
> > yMJ8Afh0VM_0Q=33=https%3a%2f%2fpastebin%2ecom%2f7C82BLGT
> >
> > but I always get the exception:
> > Caused by:
> org.springframework.beans.factory.NoSuchBeanDefinitionException:
> > No qualifying bean of type
> > 'com.camel.database.repositories.WorkflowRepository' available:
> > expected at least 1 bean which qualifies as autowire candidate.
> > Dependency
> > annotations:
> > {@org.springframework.beans.factory.annotation.Autowired(required=true
> > )}
> >
> >
> > Le lun. 1 oct. 2018 à 09:59, Valdis Andersons
> > a écrit :
> >
> > > Hi Damien,
> > >
> > > We use Spring annotations in our integrations quite a lot and it's
> > > working rather well for us. In order to invoke the RouteBuilder
> > > instance we just provide a class name for it in the
> > > ApplicationContext of the test createApplicationContext method and
> > > then use a test configuration file to specify the endpoints for it.
> > > Then we send various messages to the endpoints and assert the
> > > results when consuming
> > from the output endpoints.
> > > What is you test setup,
RE: Antwort: CXF : setting maxChildElements on endpoint
Hi, Won't setting the property on the bus be effective for all endpoints in the Camel context? Reading the doc you reference, it says: Contextual properties which will be applied to all endpoints and clients using this bus Actually, I don't know how Camel manages all the CXF endpoints that are configured in the context. Is there a shared bus for all routes using the CXF component. A bus per route? Thanks, David -Message d'origine- De : bjoern@provinzial.de [mailto:bjoern@provinzial.de] Envoyé : 4 octobre 2018 08:13 À : users@camel.apache.org Objet : Antwort: CXF : setting maxChildElements on endpoint Courriel provenant de l’externe ATTENTION, avant d’accéder à une pièce jointe ou à un lien de ce courriel, assurez-vous que celui-ci provient d’un tiers de confiance. Hi, perhaps you can use a configuration file (cxf.xml) like in http://cxf.apache.org/docs/bus-configuration.html. The entry: should work... Best regards Björn Von:"Duchaine, David" An: "users@camel.apache.org" Datum: 02.10.2018 16:27 Betreff:CXF : setting maxChildElements on endpoint Hello everyone, Camel version 2.21.2 We have configured a CXF Endpoint and getting the following exception while returning the response to the client: Maximum Number of Child Elements limit (5) Exceeded While setting the org.apache.cxf.stax.maxChildElements as a system property on the JVM works, we'd prefer to have the property applied on a specific endpoint only. As specified in the CXF Component doc, we tried setting the property on the URI as follows but it doesn't work because we still hit the default limit: properties.org.apache.cxf.stax.maxChildElements=10 We've tried adding the following property but still no avail: properties.org.apache.cxf.interceptor.OneWayProcessorInterceptor.USE_ORIGINAL_THREAD=true Are we missing something here? thanks, David Diese E-Mail könnte vertrauliche und / oder rechtlich geschützte Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht gestattet. This e-mail may contain confidential and / or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
RE: REST endpoint to rabbitmq queue connection timeout
Thank you very much Zoran, I'll try it out with those parameters and see how it
goes.
Valdis
-Original Message-
From: Zoran Regvart [mailto:zo...@regvart.com]
Sent: 05 October 2018 10:45
To: users@camel.apache.org
Subject: Re: REST endpoint to rabbitmq queue connection timeout
Hi Valdis,
I think you're looking for `channelPoolMaxSize` and `channelPoolMaxWait`
parameters[1]. From the snippet, I guess, you would set them on the
`feedbackEndpoint`, and from the message history I see that you already set the
`connectionFactory`, so you would configure these much in the same way.
zoran
[1]
https://scanmail.trustwave.com/?c=6600=prK32zpd-TqvMeNzuqm1P9sl2_MVSbEt5EF_ffZc_A=33=https%3a%2f%2fgithub%2ecom%2fapache%2fcamel%2fblob%2fmaster%2fcomponents%2fcamel-rabbitmq%2fsrc%2fmain%2fdocs%2frabbitmq-component%2eadoc
On Thu, Oct 4, 2018 at 6:15 PM, Valdis Andersons
wrote:
> Hi All,
>
>
>
> Would anyone know how to configure the timeout values for the below
> connection pool or the connection pool itself? Been having some issues
> lately in a test environment with this and the timeout check seems to
> happen every few milliseconds producing huge amounts of log files.
>
> We’re suspecting it’s a network issue that’s causing this as there is
> nothing much between the REST endpoint on the buffer queue and only if
> there is some decent load on the endpoint (10req/sec or so):
>
>
>
> rest(restEndpoint).post(postEndpoint)
> .type(FeedbackRequest.class)
> .route()
> .process(this::process)
> .startupOrder(Integer.MAX_VALUE - 2)
> .marshal().json(JsonLibrary.Jackson, String.class)
> .to(feedbackEndpoint)
> .endRest();
>
>
>
> where process() just sets a persistence header for RabbitMQ to flush
> the message to disk:
>
>
>
> exchange.getIn().setHeader("rabbitmq.DELIVERY_MODE", 2);
>
>
>
>
>
> 2018-10-04 17:01:43,275 [https-jsse-nio-8443-exec-65] ERROR
> o.a.c.p.DefaultErrorHandler ID-VM1-1538665977944-0-101281 - Failed
> delivery for (MessageId: ID-VM1-1538665977944-0-101280 on ExchangeId:
> ID-VM1-1538665977944-0-101281). Exhausted after delivery attempt: 1 caught:
> java.util.NoSuchElementException: Timeout waiting for idle object
>
>
>
> Message History
>
> --
> -
>
> RouteId ProcessorId Processor
> Elapsed (ms)
>
> [route24 ] [route24 ]
> [restlet:///cch/feedback?restletMethods=POST
> ] [ 3798]
>
> [route24 ] [process22 ] [Processor@0x37c71429
> ] [ 0]
>
> [route24 ] [marshal1 ]
> [marshal[org.apache.camel.model.dataformat.JsonDataFormat@c940d2]
> ] [ 0]
>
> [route24 ] [route24 ]
> [rabbitmq://vm1:5671/feedbackBufferExchange?connectionFactory=rabbitConnec]
> [ 3782]
>
>
>
> Stacktrace
>
> --
> -
>
> java.util.NoSuchElementException: Timeout waiting for idle object
>
> at
> org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObj
> ectPool.java:1174)
>
> at
> org.apache.camel.component.rabbitmq.RabbitMQProducer.execute(RabbitMQP
> roducer.java:73)
>
> at
> org.apache.camel.component.rabbitmq.RabbitMQProducer.basicPublish(Rabb
> itMQProducer.java:285)
>
> at
> org.apache.camel.component.rabbitmq.RabbitMQProducer.processInOnly(Rab
> bitMQProducer.java:272)
>
> at
> org.apache.camel.component.rabbitmq.RabbitMQProducer.process(RabbitMQP
> roducer.java:195)
>
> at
> org.apache.camel.processor.SendProcessor.process(SendProcessor.java:14
> 8)
>
> at
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryEr
> rorHandler.java:548)
>
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInterna
> lProcessor.java:201)
>
> at
> org.apache.camel.processor.Pipeline.process(Pipeline.java:138)
>
> at
> org.apache.camel.processor.Pipeline.process(Pipeline.java:101)
>
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInterna
> lProcessor.java:201)
>
> at
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyn
> cProcessor.java:97)
>
> at
> org.apache.camel.component.restlet.RestletConsumer$1.handle(RestletCon
> sumer.java:68)
>
> at
> org.apache.camel.component.restlet.MethodBasedRouter.handle(MethodBase
> dRouter.java:58)
>
>
>
>
>
> Thanks,
>
> Valdis
>
>
> Vhi Group DAC (Vhi) is a holding company for insurance and healthcare
> services, which include Vhi Healthcare DAC, Vhi Insurance DAC, Vhi
> Health Services DAC and Vhi Investments DAC. Vhi Healthcare DAC
> trading as Vhi Healthcare and Vhi Insurance
Re: REST endpoint to rabbitmq queue connection timeout
Hi Valdis,
I think you're looking for `channelPoolMaxSize` and
`channelPoolMaxWait` parameters[1]. From the snippet, I guess, you
would set them on the `feedbackEndpoint`, and from the message history
I see that you already set the `connectionFactory`, so you would
configure these much in the same way.
zoran
[1]
https://github.com/apache/camel/blob/master/components/camel-rabbitmq/src/main/docs/rabbitmq-component.adoc
On Thu, Oct 4, 2018 at 6:15 PM, Valdis Andersons
wrote:
> Hi All,
>
>
>
> Would anyone know how to configure the timeout values for the below
> connection pool or the connection pool itself? Been having some issues
> lately in a test environment with this and the timeout check seems to happen
> every few milliseconds producing huge amounts of log files.
>
> We’re suspecting it’s a network issue that’s causing this as there is
> nothing much between the REST endpoint on the buffer queue and only if there
> is some decent load on the endpoint (10req/sec or so):
>
>
>
> rest(restEndpoint).post(postEndpoint)
> .type(FeedbackRequest.class)
> .route()
> .process(this::process)
> .startupOrder(Integer.MAX_VALUE - 2)
> .marshal().json(JsonLibrary.Jackson, String.class)
> .to(feedbackEndpoint)
> .endRest();
>
>
>
> where process() just sets a persistence header for RabbitMQ to flush the
> message to disk:
>
>
>
> exchange.getIn().setHeader("rabbitmq.DELIVERY_MODE", 2);
>
>
>
>
>
> 2018-10-04 17:01:43,275 [https-jsse-nio-8443-exec-65] ERROR
> o.a.c.p.DefaultErrorHandler ID-VM1-1538665977944-0-101281 - Failed delivery
> for (MessageId: ID-VM1-1538665977944-0-101280 on ExchangeId:
> ID-VM1-1538665977944-0-101281). Exhausted after delivery attempt: 1 caught:
> java.util.NoSuchElementException: Timeout waiting for idle object
>
>
>
> Message History
>
> ---
>
> RouteId ProcessorId Processor
> Elapsed (ms)
>
> [route24 ] [route24 ]
> [restlet:///cch/feedback?restletMethods=POST
> ] [ 3798]
>
> [route24 ] [process22 ] [Processor@0x37c71429
> ] [ 0]
>
> [route24 ] [marshal1 ]
> [marshal[org.apache.camel.model.dataformat.JsonDataFormat@c940d2]
> ] [ 0]
>
> [route24 ] [route24 ]
> [rabbitmq://vm1:5671/feedbackBufferExchange?connectionFactory=rabbitConnec]
> [ 3782]
>
>
>
> Stacktrace
>
> ---
>
> java.util.NoSuchElementException: Timeout waiting for idle object
>
> at
> org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1174)
>
> at
> org.apache.camel.component.rabbitmq.RabbitMQProducer.execute(RabbitMQProducer.java:73)
>
> at
> org.apache.camel.component.rabbitmq.RabbitMQProducer.basicPublish(RabbitMQProducer.java:285)
>
> at
> org.apache.camel.component.rabbitmq.RabbitMQProducer.processInOnly(RabbitMQProducer.java:272)
>
> at
> org.apache.camel.component.rabbitmq.RabbitMQProducer.process(RabbitMQProducer.java:195)
>
> at
> org.apache.camel.processor.SendProcessor.process(SendProcessor.java:148)
>
> at
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:548)
>
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
>
> at
> org.apache.camel.processor.Pipeline.process(Pipeline.java:138)
>
> at
> org.apache.camel.processor.Pipeline.process(Pipeline.java:101)
>
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
>
> at
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:97)
>
> at
> org.apache.camel.component.restlet.RestletConsumer$1.handle(RestletConsumer.java:68)
>
> at
> org.apache.camel.component.restlet.MethodBasedRouter.handle(MethodBasedRouter.java:58)
>
>
>
>
>
> Thanks,
>
> Valdis
>
>
> Vhi Group DAC (Vhi) is a holding company for insurance and healthcare
> services, which include Vhi Healthcare DAC, Vhi Insurance DAC, Vhi Health
> Services DAC and Vhi Investments DAC. Vhi Healthcare DAC trading as Vhi
> Healthcare and Vhi Insurance DAC trading as Vhi Insurance are regulated by
> the Central Bank of Ireland. Vhi Healthcare is tied to Vhi Insurance DAC for
> health insurance in Ireland which is underwritten by Vhi Insurance DAC. Vhi
> Healthcare is tied to Zurich Life Assurance plc for Vhi Life Term Insurance
> and Vhi Mortgage Protection which is underwritten by Zurich Life Assurance
> plc. Vhi Healthcare is tied to Collinson Insurance Services Limited for
> MultiTrip Travel Insurance,
RE: Consuming MLLP uri cannot be "seen" with localhost or 127.0.0.1 from external
Hi,
I am not sure if I get your question. If you bind the listening socket to
localhost: 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:
(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
Sent: Donnerstag, 4. Oktober 2018 15:55
To: Users
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:") This works
from("mllp://localhost:") 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!
