git.net

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

Re: Empty/null response from netty4-http template producer


Owain,

Thank you for taking a look.  You are right, I made a mistake while preparing this stripped down project.   The truth is that the Rest DSL is actually not needed to reproduce this particular issue, so I have now removed the Rest DSL and kept only a single route consuming from Netty-HTTP endpoint.  Still, the problem persists.   I can see the route traces in the logs, so it appears the route is being called, and returning a payload:


>>> (echo-route) from(http://127.0.0.1:8080/echo) --> setBody[Simple: ${body}] <<< Pattern:InOut,
>>> (echo-route) setBody[Simple: ${body}] --> setHeader[Content-Type, application/octet-stream] <<< Pattern:InOut,
populateCamelHeaders: HttpObjectAggregator$AggregatedFullHttpResponse(decodeResult: success, version: HTTP/1.1, content: CompositeByteBuf(ridx: 0, widx: 38, cap: 38, components=1))
HTTP/1.1 200 OK
content-length: 38
content-type: application/octet-stream
connection: keep-alive

I have looked into the unit tests in Camel source, which are doing something similar and it works there, so I can’t figure out why it wouldn’t work for me.  Can you take a took now?


Best regards,
Alex soto



> On Mar 27, 2018, at 3:18 AM, Owain McGuire <owain@integration.technology> wrote:
> 
> Alex,
> 
> Just had a quick look.  
> 
> The post in the Rest DSL route goes to direct:echo-route but your echo-route does not have a "from direct:echo-route". My understanding is that the REST DSL generates a route that will have already consumed the POST and then once it has sent the exchange to the direct:echo-route it thinks it has just finished.  Hence returns with no body.  echo-route never receives an exchange.
> 
> O.
> 
> 
>> On 26 Mar 2018, at 18:51, Alex Soto <alex.soto@xxxxxxxxxxx> wrote:
>> 
>> Hello,
>> 
>> I have put a simple project that demonstrates this problem.  This does not appear to be related to stream caching, as I have enable stream caching in both Camel contexts.
>> 
>> https://github.com/lexsoto/camel-karaf-netty-producer-test/tree/master <https://github.com/lexsoto/camel-karaf-netty-producer-test/tree/master> <https://github.com/lexsoto/camel-karaf-netty-producer-test/tree/master <https://github.com/lexsoto/camel-karaf-netty-producer-test/tree/master>>
>> 
>> Can anybody take a look and let me know what I am doing wrong?
>> 
>> Thanks and best regards,
>> Alex soto
>> 
>> 
>> 
>>> On Feb 22, 2018, at 5:42 PM, Alex Soto <alex.soto@xxxxxxxxxxx <mailto:alex.soto@xxxxxxxxxxx>> wrote:
>>> 
>>> Hello,
>>> 
>>> I am having some problems migrating to Camel 2.20.2 from 2.17.4.    This has been working before, but now the response is null.
>>> I have access to the server logs and everything there looks good, i.e., the server is sending a response, but client is unable to get it.
>>> Here is the client code:
>>> 
>>> 		SimpleRegistry registry = new SimpleRegistry();
>>> 		registry.put("sslParams", sslContextParams);
>>> 
>>> 		DefaultCamelContext defaultCamelContext = new DefaultCamelContext(registry);
>>> 		defaultCamelContext.addComponent("netty4-http", new NettyHttpComponent());
>>> 		defaultCamelContext.setTracing(true);
>>> 		defaultCamelContext.setName("itest");
>>> 		defaultCamelContext.setStreamCaching(true);
>>> 		defaultCamelContext.start();
>>> 
>>> 		ProducerTemplate producerTemplate = defaultCamelContext.createProducerTemplate();
>>> 		producerTemplate.start();
>>> 
>>> 		final BytesAndDecParams requestMessage = makeEnrolCertRequest();
>>> 
>>> 		byte[] response = producerTemplate.requestBody(
>>> 				"netty4-http:https://localhost:8895/service?sslContextParameters=#sslParams&ssl=true <https://localhost:8895/service?sslContextParameters=#sslParams&ssl=true> <https://localhost:8895/service?sslContextParameters=#sslParams&ssl=true <https://localhost:8895/service?sslContextParameters=#sslParams&ssl=true>>",
>>> 				requestMessage.message,
>>> 				byte[].class);
>>> 
>>> 		assertNotNull(response);
>>> 
>>> 
>>> I appreciate any help with this problem.
>>> Best regards,
>>> Alex soto
>