date:20171220

Re: Jetty consumer responds with a 500 error java.io.IOException: Response header too large

2017-12-20 Thread Laurentiu Trica

Camel version: 2.16.3

Thanks!

On Tue, Dec 19, 2017 at 6:27 PM, Andrea Cosentino <
ancosen1...@yahoo.com.invalid> wrote:

> What version of camel are you using?
>
> Inviato da Yahoo Mail su Android
>
>   Il mar, 19 dic, 2017 alle 16:45, Laurentiu Trica moredevs.ro> ha scritto:   Hello,
>
> I have a problem with the Jetty consumer. I receive a file with an attached
> file (Multi-Part Form), but if the file is bigger than a few KB, I get the
> bellow Stack trace. If the file is smaller, everything works fine.
>
> The strange part is that for a size of 80KB I still receive the file in the
> route, but the response to the HTTP client is:
> HTTP/1.1 500 Server Error
> Connection: close
> Server: Jetty(9.2.14.v20151106)
>
> If the file's size is, let's say, 2 MB, then the route doesn't get the file
> anymore and the response to the client is the same.
>
> I tried to set the request/response buffers to bigger values, but it didn't
> help:
> http://0.0.0.0:9086/Test?responseHeaderSize=32768000;
> responseBufferSize=32768000=32768000&
> requestHeaderSize=32768000
> "/>
>
> Any ideas? Can you please help?
>
> *Stack trace:*
> 2017-12-19 16:33:02,802 | WARN  | tp466415455-3362 | ServletHandler
>   | 119 - org.eclipse.jetty.util - 9.2.14.v20151106 | /Test
> java.io.IOException: Response header too large
> at
> org.eclipse.jetty.http.HttpGenerator.generateResponse(
> HttpGenerator.java:400)[107:org.eclipse.jetty.http:9.2.14.v20151106]
> at
> org.eclipse.jetty.server.HttpConnection$SendCallback.
> process(HttpConnection.java:655)[116:org.eclipse.jetty.
> server:9.2.14.v20151106]
> at
> org.eclipse.jetty.util.IteratingCallback.processing(
> IteratingCallback.java:246)[119:org.eclipse.jetty.util:9.2.14.v20151106]
> at
> org.eclipse.jetty.util.IteratingCallback.iterate(
> IteratingCallback.java:208)[119:org.eclipse.jetty.util:9.2.14.v20151106]
> at
> org.eclipse.jetty.server.HttpConnection.send(HttpConnection.java:471)[116:
> org.eclipse.jetty.server:9.2.14.v20151106]
> at
> org.eclipse.jetty.server.HttpChannel.sendResponse(
> HttpChannel.java:763)[116:org.eclipse.jetty.server:9.2.14.v20151106]
> at
> org.eclipse.jetty.server.HttpChannel.write(HttpChannel.
> java:801)[116:org.eclipse.jetty.server:9.2.14.v20151106]
> at
> org.eclipse.jetty.server.HttpOutput.write(HttpOutput.
> java:147)[116:org.eclipse.jetty.server:9.2.14.v20151106]
> at
> org.eclipse.jetty.server.HttpOutput.write(HttpOutput.
> java:140)[116:org.eclipse.jetty.server:9.2.14.v20151106]
> at
> org.eclipse.jetty.server.HttpOutput.flush(HttpOutput.
> java:242)[116:org.eclipse.jetty.server:9.2.14.v20151106]
> at
> org.apache.camel.util.IOHelper.copy(IOHelper.java:
> 201)[59:org.apache.camel.camel-core:2.16.3]
> at
> org.apache.camel.http.common.DefaultHttpBinding.copyStream(
> DefaultHttpBinding.java:369)[143:org.apache.camel.camel-
> http-common:2.16.3]
> at
> org.apache.camel.http.common.DefaultHttpBinding.doWriteDirectResponse(
> DefaultHttpBinding.java:433)[143:org.apache.camel.camel-
> http-common:2.16.3]
> at
> org.apache.camel.http.common.DefaultHttpBinding.doWriteResponse(
> DefaultHttpBinding.java:332)[143:org.apache.camel.camel-
> http-common:2.16.3]
> at
> org.apache.camel.http.common.DefaultHttpBinding.writeResponse(
> DefaultHttpBinding.java:264)[143:org.apache.camel.camel-
> http-common:2.16.3]
> at
> org.apache.camel.component.jetty.CamelContinuationServlet.service(
> CamelContinuationServlet.java:227)[155:org.apache.camel.
> camel-jetty-common:2.16.3]
> at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:790)[54:
> javax.servlet-api:3.1.0]
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(
> ServletHolder.java:812)[117:org.eclipse.jetty.servlet:9.2.14.v20151106]
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.
> doFilter(ServletHandler.java:1669)[117:org.eclipse.jetty.
> servlet:9.2.14.v20151106]
> at
> org.apache.camel.component.jetty.CamelFilterWrapper.
> doFilter(CamelFilterWrapper.java:45)[155:org.apache.camel.
> camel-jetty-common:2.16.3]
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.
> doFilter(ServletHandler.java:1652)[117:org.eclipse.jetty.
> servlet:9.2.14.v20151106]
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(
> ServletHandler.java:585)[117:org.eclipse.jetty.servlet:9.2.14.v20151106]
> at
> org.eclipse.jetty.server.handler.ContextHandler.
> doHandle(ContextHandler.java:1127)[116:org.eclipse.jetty.
> server:9.2.14.v20151106]
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(
> ServletHandler.java:515)[117:org.eclipse.jetty.servlet:9.2.14.v20151106]
> at
> org.eclipse.jetty.server.handler.ContextHandler.
> doScope(ContextHandler.java:1061)[116:org.eclipse.jetty.
> server:9.2.14.v20151106]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(
> ScopedHandler.java:141)[116:org.eclipse.jetty.server:9.2.14.v20151106]
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(
> HandlerWrapper.java:97)[116:org.eclipse.jetty.server:9.2.14.v20151106]

Re: Question about using Splitter

2017-12-20 Thread Charles Berger

> You should be able to convert your ImageCollection into List
> by simply doing something like:
>
> from("activemq:requestQueue")
> .convertBodyTo(ImageCollection.class)
> .setBody(simple("${body.images}"))
> .log("${body}")
> .split(body())
> .log("${body}")
> .to("bean:downloadImageQueue")
> .marshal().json(JsonLibrary.Jackson)
> .to("activemq:ftpQueue");

That has worked - thank you so much - I had spent way too long trying
to get past that step.

Re: Question about using Splitter

2017-12-20 Thread Charles Berger

Hi,

Thanks for replying.

> Instead of splitting ImageCollection as the body, I think you just need to
> split List as the body.

Are you suggesting that the ImageCollection class is actually
superfluous and I should use the List as the output
from the bean uploadRequestQueue instead?

Or is there a way in the route that I can call the method
ImageCollection.getImages() method to pass into the split?

Thanks,

Charles.

Re: Question about using Splitter

2017-12-20 Thread Tadayoshi Sato

Hi,

The point is that to split object message body using Splitter DSL it needs
to be either Collection, Iterator, or array. ImageCollection is a custom
class so there's no way for Camel to know how to split it.

You should be able to convert your ImageCollection into List
by simply doing something like:

from("activemq:requestQueue")
.convertBodyTo(ImageCollection.class)
.setBody(simple("${body.images}"))
.log("${body}")
.split(body())
.log("${body}")
.to("bean:downloadImageQueue")
.marshal().json(JsonLibrary.Jackson)
.to("activemq:ftpQueue");



On Wed, Dec 20, 2017 at 5:07 PM, Charles Berger <
charlesb.yesm...@googlemail.com> wrote:

> Hi,
>
> Thanks for replying.
>
> > Instead of splitting ImageCollection as the body, I think you just need
> to
> > split List as the body.
>
> Are you suggesting that the ImageCollection class is actually
> superfluous and I should use the List as the output
> from the bean uploadRequestQueue instead?
>
> Or is there a way in the route that I can call the method
> ImageCollection.getImages() method to pass into the split?
>
> Thanks,
>
> Charles.
>

Re: Invoke Camel Backlog Tracer

2017-12-20 Thread Joery Vreijsen

Thanks, i believe it is working now.

Unfortunately i don’t think logging to log files will do it for me.

My goal is to create an api endpoint that can retrieve the traced
messages from the Backlog Queue.
In the api endpoint i have access to the Camel Context (and thus the
backlogTracer), but i’m looking for a way to deploy the blueprint xml
with the backlog tracer enabled.

I tried setting the trace=“true” property to see if it enables the
backlogTracer on startup, but with no luck.

2017-12-20 12:37 GMT+01:00 Claus Ibsen :
> Hi
>
> Replying again as there may be an issue with Joery seeing the mails from here
>
> If you just want to have tracing to log files, then using "trace=true"
> in  is not deprecated and you can use that.
>
> On Tue, Dec 19, 2017 at 5:09 PM, Joery Vreijsen  wrote:
>> Hi There!
>>
>> First of all this is my first time posting in the the mailing list, so
>> any feedback is appreciated.
>>
>> Im currently experimenting with the Backlog Tracer as we are currently
>> upgrading our application to Camel 2.20.1 and the “old” Tracer is
>> Deprecated.
>> In the documentation (http://camel.apache.org/backlogtracer.html) i
>> was looking for an example to invoke the Backlog Tracer in a Blueprint
>> xml.
>>
>> This is what i tried (as it was working for the Tracer):
>>
>> 
>> http://www.osgi.org/xmlns/blueprint/v1.0.0;
>>xmlns:camel="http://camel.apache.org/schema/blueprint;
>>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
>>http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd;>
>>
>> > class="org.apache.camel.processor.interceptor.BacklogTracer">
>> 
>> 
>>
>> > xmlns="http://camel.apache.org/schema/blueprint”>
>> // Example route
>> 
>> 
>> 
>> 
>> 
>>
>> 
>>
>> Unfortunately this results in the blueprint saying the BacklogTracer
>> is already instantiated.
>> org.osgi.service.blueprint.container.ComponentDefinitionException:
>> Name backlogTracer is already instanciated as null and cannot be
>> removed.
>>
>> Any suggestions how to enable the Backlog Tracer by default in a blueprint 
>> xml?
>>
>> All help is appreciated!
>>
>> Greetings,
>>
>> - Joery
>
>
>
> --
> Claus Ibsen
> -
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2

Re: Invoke Camel Backlog Tracer

2017-12-20 Thread Claus Ibsen

Hi

Replying again as there may be an issue with Joery seeing the mails from here

If you just want to have tracing to log files, then using "trace=true"
in  is not deprecated and you can use that.

On Tue, Dec 19, 2017 at 5:09 PM, Joery Vreijsen  wrote:
> Hi There!
>
> First of all this is my first time posting in the the mailing list, so
> any feedback is appreciated.
>
> Im currently experimenting with the Backlog Tracer as we are currently
> upgrading our application to Camel 2.20.1 and the “old” Tracer is
> Deprecated.
> In the documentation (http://camel.apache.org/backlogtracer.html) i
> was looking for an example to invoke the Backlog Tracer in a Blueprint
> xml.
>
> This is what i tried (as it was working for the Tracer):
>
> 
> http://www.osgi.org/xmlns/blueprint/v1.0.0;
>xmlns:camel="http://camel.apache.org/schema/blueprint;
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
>http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd;>
>
>  class="org.apache.camel.processor.interceptor.BacklogTracer">
> 
> 
>
>  xmlns="http://camel.apache.org/schema/blueprint”>
> // Example route
> 
> 
> 
> 
> 
>
> 
>
> Unfortunately this results in the blueprint saying the BacklogTracer
> is already instantiated.
> org.osgi.service.blueprint.container.ComponentDefinitionException:
> Name backlogTracer is already instanciated as null and cannot be
> removed.
>
> Any suggestions how to enable the Backlog Tracer by default in a blueprint 
> xml?
>
> All help is appreciated!
>
> Greetings,
>
> - Joery



-- 
Claus Ibsen
-
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Re: Jetty consumer responds with a 500 error java.io.IOException: Response header too large

2017-12-20 Thread Roman Vottner

Do you somehow store the received file into camel headers? Camel will 
return most headers to the invoker and usually HTTP headers > 8kb will 
produce that kind of exception.


You might want to introduce a customized HttpHeaderFilterStrategy 
similar to the sample below to avoid returning certain headers.


import org.apache.camel.Exchange;
import org.apache.camel.http.common.HttpHeaderFilterStrategy;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import java.lang.invoke.MethodHandles;
import java.util.Arrays;
import java.util.List;

public class CustomHeaderFilterStrategy extends HttpHeaderFilterStrategy {

  private final static Logger LOG = 
LoggerFactory.getLogger(MethodHandles.lookup().lookupClass());
  private boolean debugLog = false;

  protected List queryParamsToFilter = Arrays.asList("appKey", "limit", "offset", 
"filter");
  protected List otherParamsToFilter =
  Arrays.asList("breadcrumbId", "User-Agent", "NewRelicID", 
"NewRelicTransaction",
"Transfer-Encoding", "Authorization", "Accept",
"HttpResponseContent", "TLS_PROTOCOL_VERSION", 
"TLS_CIPHER_SUITE");

  public CustomHeaderFilterStrategy() {

  }

  public CustomHeaderFilterStrategy(boolean debugLog) {
this.debugLog = debugLog;
  }

  // outgoing headers
  @Override
  public boolean applyFilterToCamelHeaders(String headerName, Object 
headerValue,
   Exchange exchange) {

// do not copy Camel specific headers from the Camel exchange to the out 
headers
if (super.applyFilterToCamelHeaders(headerName, headerValue, exchange)) {
  if (debugLog) {
LOG.debug("Filtered header {} through HTTP header filter", headerName);
  }
  return true;
}

// do not copy SAMPLE_* headers from the Camel exchange to the out headers
if (headerName.startsWith("SAMPLE_")) {
  if (debugLog) {
LOG.debug("Filtering header {}", headerName);
  }
  return true;
}
if (headerName.startsWith("JMS")) {
  if (debugLog) {
LOG.debug("Filtering header {}", headerName);
  }
  return true;
}
if (queryParamsToFilter.contains(headerName)) {
  if (debugLog) {
LOG.debug("Filtering header {}", headerName);
  }
  return true;
}
if (otherParamsToFilter.contains(headerName)) {
  if (debugLog) {
LOG.debug("Filtering header: {}", headerName);
  }
  return true;
}

if (debugLog) {
  LOG.debug("Outgoing header passed: {} - value: {}", headerName, 
headerValue);
}
return false;
  }

  // incoming headers
  @Override
  public boolean applyFilterToExternalHeaders(String headerName, Object 
headerValue,
  Exchange exchange) {
// allow all headers to be copied from the request to camel headers
return false;
  }
}

You can utilize this custom header filter by appending 
?headerFilterStrategy=#refNameOfFilterStrategy to the route specifying 
the Jetty consumer, where "refNameOfFilterStrategy" is the name you 
register the class above with Camel (or Spring).


This thread 
(https://stackoverflow.com/questions/17550471/camel-jetty-component-custom-header-filter-strategy) 
also states that you may customize the DefaultHttpBinding, though I'd 
try the primer solution first.


HTH,

Roman

Am 20.12.2017 um 09:42 schrieb Laurentiu Trica:

Camel version: 2.16.3

Thanks!

On Tue, Dec 19, 2017 at 6:27 PM, Andrea Cosentino <
ancosen1...@yahoo.com.invalid> wrote:


What version of camel are you using?

Inviato da Yahoo Mail su Android

   Il mar, 19 dic, 2017 alle 16:45, Laurentiu Trica ha scritto:   Hello,

I have a problem with the Jetty consumer. I receive a file with an attached
file (Multi-Part Form), but if the file is bigger than a few KB, I get the
bellow Stack trace. If the file is smaller, everything works fine.

The strange part is that for a size of 80KB I still receive the file in the
route, but the response to the HTTP client is:
HTTP/1.1 500 Server Error
Connection: close
Server: Jetty(9.2.14.v20151106)

If the file's size is, let's say, 2 MB, then the route doesn't get the file
anymore and the response to the client is the same.

I tried to set the request/response buffers to bigger values, but it didn't
help:
http://0.0.0.0:9086/Test?responseHeaderSize=32768000;
responseBufferSize=32768000=32768000&
requestHeaderSize=32768000
"/>

Any ideas? Can you please help?

*Stack trace:*
2017-12-19 16:33:02,802 | WARN  | tp466415455-3362 | ServletHandler
   | 119 - org.eclipse.jetty.util - 9.2.14.v20151106 | /Test
java.io.IOException: Response header too large
at
org.eclipse.jetty.http.HttpGenerator.generateResponse(
HttpGenerator.java:400)[107:org.eclipse.jetty.http:9.2.14.v20151106]
at
org.eclipse.jetty.server.HttpConnection$SendCallback.
process(HttpConnection.java:655)[116:org.eclipse.jetty.
server:9.2.14.v20151106]
at

Re: MockEndpoint does not receive message if error occures in subroute

2017-12-20 Thread Quinn Stevenson

I’m not sure why this is working in the real world, but the reason the test is 
failing is the default error handler is picking up the exception from the call 
to the direct://Validate  route.  If you add 
".errorHandler(new NoErrorHandlerBuilder())” to the direct://Validate 
 route, your test will pass.

Quinn Stevenson
qu...@pronoia-solutions.com
(801) 244-7758



> On Dec 1, 2017, at 6:07 AM, Burkard Stephan  wrote:
> 
> Hi Camel users
> 
> I have attached a simplified example project (Maven) to illustrate a strange 
> problem I have in the tests of a current project. 
> 
> *** Setup ***
> - There is a Camel route that receives messages
> - It sends them to a validation subroute
> - The validation subroute uses a choice/when block to check a header value
> 
> - If the header is ok, the message goes to the standard output endpoint
> - If the header is wrong, an exception is thrown and the error handler kicks 
> in
> - The error handler sends the message to an alternative endpoint
> 
> *** Problem ***
> If you open the project and run the route tests, you will see that one test 
> fails. 
> - It sends a message with the wrong header, so an exception is thrown
> - In the console output you can see that the error route processes the 
> message (as expected)
> ==> But the error endpoint mock does not receive the message (WHY? This is 
> wrong!)
> 
> *** It works in real life ***
> - When I run the real project with the real endpoints, the error endpoint 
> produces the messages
> - It is only in the test this does not work
> 
> *** Strange effect *** 
> When I move the choice/when block from the subroute to the main route, the 
> test is successful
> 
> Can anyone explain this? Is this a bug or am I doing/expecting something 
> wrong?
> 
> Thanks
> Stephan
> 
> 
>

Re: HL7/Using terser in Bean

2017-12-20 Thread Quinn Stevenson

If I understand what you’re asking, you could use a HAPI Terser 
(https://hapifhir.github.io/hapi-hl7v2/base/apidocs/ca/uhn/hl7v2/util/Terser.html
 
)
 in your bean.

HTH

Quinn Stevenson
qu...@pronoia-solutions.com
(801) 244-7758



> On Oct 26, 2017, at 10:35 AM, Walzer, Thomas  
> wrote:
> 
> Hi everyone,
> 
> I think I painted myself into a mental corner.
> 
> Goal is to achieve a canonical dataformat to log my HL7 messages.
> 
> I would like to accomodate various HL7 versions/event types where I need 
> different terser expressions like
> /PATIENT_RESULT/PATIENT/PV1-19-1 or
> /RESPONSE/PATIENT/VISIT/PV1-19-1 for PV1-19.
> These expressions are dependent on version, event type, etc.
> 
> In my route the expressions work ok, however I have lots of choice/when 
> decisions which breaks easily. So I thought about putting that logic into a 
> bean.
> That works great with @Terser language annotations. However those expressions 
> are fixed. I would have loved to use terser expressions in the bean. Like so:
> 
> if (versionId.equalsIgnoreCase("2.2")) {
>headers.put(„dob", terser("/PATIENT_RESULT/PATIENT/PID-7-1"));
>headers.put(„surname", 
> terser("/PATIENT_RESULT/PATIENT/PID-5-1"));
>headers.put(„name", terser("/PATIENT_RESULT/PATIENT/PID-5-2"));
>headers.put("pid", terser("/PATIENT_RESULT/PATIENT/PID-3-1"));
>headers.put(„caseno", 
> terser("/PATIENT_RESULT/PATIENT/PV1-19-1"));
> } else if (versionId.equalsIgnoreCase("2.3")) {
>headers.put(„dob", terser("/RESPONSE/PATIENT/PID-7-1"));
>headers.put(„surname", terser("/RESPONSE/PATIENT/PID-5-1"));
>headers.put(„name", terser("/RESPONSE/PATIENT/PID-5-2"));
>headers.put("pid", terser("/RESPONSE/PATIENT/PID-3-1"));
>headers.put(„caseno", 
> terser("/RESPONSE/PATIENT/VISIT/PV1-19-1"));
> 
> Is this possible? Or are there other approaches I am currently missing?
> 
> I created a sample in https://github.com/twalzer/tersertest that kinda works. 
> But not like sketched above. Any hints?
> 
> Cheers, Thomas.
> 
> 
> 
> 
>

Re: JMS Acknowledge mode

2017-12-20 Thread Quinn Stevenson

I’m not sure I’m following you, but I can tell you what I normally do.

My JMS Consumers use “transacted=true”, which will use a JMS Session 
transaction.  You don’t need the acknowledgementModeName, and I don’t think you 
need ‘.transacted()’ (I believe this is for XA).

I then setup exception policies for the different types of exceptions, with 
appropriate redelivery handling.

For the case where I don’t have an exception policy for an exception, Camel 
will rollback the message.  I also use ActiveMQ, so the message will get moved 
to a DLQ after being rolled-back 6 times.

HTH

Quinn Stevenson
qu...@pronoia-solutions.com
(801) 244-7758

> On Sep 4, 2017, at 5:21 AM, Andreas Bergmann  wrote:
> 
> Hi all,
> 
> I have the scenario where I need to manipulate the acknowledgement of JMS
> messages, depending on exceptions.
> 
> The setup so far:
> I configured the JMS endpoint with
> '=true=SESSION_TRANSACTED' and I
> added .transacted() to the route definition.
> 
> As soon as I have an Exception the messages will not be acknowledged and
> 'redelivered' from the JMS - so far so good.
> 
> But I have several steps in the route, some of them have recoverable, some
> unrecoverable reasons.
> I first parse the incoming message and in case of an exception I do not
> want the JMS to be acknowledged, since this is an unrecoverable error.
> Then I consume the message, which includes a validation and an own 'retry
> handling' in case of an exception - in this case the JMS message should be
> acknowledged.
> In case of other Exceptions (i.e. na db connection) I do not want the
> message to be acknowledged.
> 
> I tried several options with 'doCatch', 'onException', 'setFault in the
> Consumer','.handled(true)', '.stop()'  - but found no way to solve this
> problem. I can either switch to 'always acknowledge in case of an
> exception' or 'never acknowledge on exception'.
> 
> Any ideas or examples?
> 
> Best regards,
> Andreas

RE: netty4-http send chunked response

2017-12-20 Thread Sharples, Colin

Even weirder, this only seems to happen on Solaris. If I run my route on Linux, 
then I get the proper string without the chunked encoding characters.

I found this, which suggests that it might just be a bug in the JDK: 
http://www-01.ibm.com/support/docview.wss?uid=swg21255293

I'd still like to be able to get my simulated DataPower route to send a chunked 
response, though. Any ideas on how I can do that?

-Original Message-
From: Sharples, Colin [mailto:colin.sharp...@anz.com]
Sent: Tuesday, 12 December 2017 6:00 p.m.
To: users@camel.apache.org
Subject: netty4-http send chunked response

I have a route that sends to a service running on DataPower, which by default 
sends responses as Transfer-Encoding: chunked.

I need to be able to set up a route to use in a test case that simulates this 
service, but I can't see any way to tell a netty4-http consumer to send a 
chunked response.

I've seen some old pages that suggest there is an option chunked=Boolean on the 
netty4-http component, but it is not mentioned in the 2.18 documentation. I 
tried setting it anyway, and it didn't seem to make a difference. At least, the 
message came back with a header chunked: true, but not Transfer-Encoding: 
chunked.

When I hook up the route to the DataPower service, when I get the response body 
as a string, it still has the chunked encoding in it - a hex integer indicating 
the length at the start, and a zero on the end to indicate the last chunk. I'm 
expecting the body to be a JSON string, so first I have to chop of the chunked 
encoding parts to get the proper JSON. Seems weird that I have to do this 
manually.

Is there another setting to tell it to use the right Transfer-Encoding?

Colin Sharples

"This e-mail and any attachments to it (the "Communication") is, unless 
otherwise stated, confidential, may contain copyright material and is for the 
use only of the intended recipient. If you receive the Communication in error, 
please notify the sender immediately by return e-mail, delete the Communication 
and the return e-mail, and do not read, copy, retransmit or otherwise deal with 
it. Any views expressed in the Communication are those of the individual sender 
only, unless expressly stated to be those of Australia and New Zealand Banking 
Group Limited ABN 11 005 357 522, or any of its related entities including ANZ 
Bank New Zealand Limited (together "ANZ"). ANZ does not accept liability in 
connection with the integrity of or errors in the Communication, computer 
virus, data corruption, interference or delay arising from or in respect of the 
Communication."
"This e-mail and any attachments to it (the "Communication") is, unless 
otherwise stated, confidential, may contain copyright material and is for the 
use only of the intended recipient. If you receive the Communication in error, 
please notify the sender immediately by return e-mail, delete the Communication 
and the return e-mail, and do not read, copy, retransmit or otherwise deal with 
it. Any views expressed in the Communication are those of the individual sender 
only, unless expressly stated to be those of Australia and New Zealand Banking 
Group Limited ABN 11 005 357 522, or any of its related entities including ANZ 
Bank New Zealand Limited (together "ANZ"). ANZ does not accept liability in 
connection with the integrity of or errors in the Communication, computer 
virus, data corruption, interference or delay arising from or in respect of the 
Communication."

Re: Jetty consumer responds with a 500 error java.io.IOException: Response header too large

Re: Question about using Splitter

Re: Question about using Splitter

Re: Question about using Splitter

Re: Invoke Camel Backlog Tracer

Re: Invoke Camel Backlog Tracer

Re: Jetty consumer responds with a 500 error java.io.IOException: Response header too large

Re: MockEndpoint does not receive message if error occures in subroute

Re: HL7/Using terser in Bean

Re: JMS Acknowledge mode

RE: netty4-http send chunked response

11 matches

Site Navigation

Mail list logo

Footer information