You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by "Walzer, Thomas" <th...@integratix.net> on 2016/01/19 16:54:28 UTC
HL7/netty4/BodyType: io.netty.buffer.UnpooledUnsafeDirectByteBuf
Hi,
camel-2.15.2
I can successfully send to a HL7-Server, however I have troubles accessing the resulting ACK.
Unfortunately it is of type UnpooledUnsafeDirectByteBuf and type conversion to string fails:
....On delivery attempt: 2 caught: org.apache.camel.TypeConversionException: Error during type conversion from type: java.lang.String to the required type: java.lang.String with value UnpooledUnsafeDirectByteBuf(freed) due io.netty.util.IllegalReferenceCountException: refCnt: 0
Any ideas how to work with the ACK (besides logging which works)?
Cheers, Thomas.
Re: HL7/netty4/BodyType:
io.netty.buffer.UnpooledUnsafeDirectByteBuf
Posted by Willem Jiang <wi...@gmail.com>.
It looks like netty handler just releases the UnpooledUnsafeDirectByteBuf automatically.
Can you show us a simple test case of it?
--
Willem Jiang
Blog: http://willemjiang.blogspot.com (English)
http://jnn.iteye.com (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On January 20, 2016 at 7:23:30 PM, Walzer, Thomas (thomas.walzer@integratix.net) wrote:
> I tried . If I try that:
> ...invalidpayloadexception: no body available of type: java.lang.String but has
> value: UnpooledUnsafeDirectByteBuf(freed) of type: io.netty.buffer.UnpooledUnsafeDirectByteBuf
> on...
>
> I am sorry, logging does and did not really work. I had many headers that looked like the
> body. The body is of type UnpooledUnsafeDirectByteBuf. It does not show with the log-component.
> And it does not show using the log eip.
>
> Cheers, Thomas.
>
>
> > Am 20.01.2016 um 11:27 schrieb Willem Jiang :
> >
> > Can you just turn the message into String before logging it?
> > It looks like the UnpooledUnsafeDirectByteBuf is consumed.
> >
> > --
> > Willem Jiang
> >
> >
> > Blog: http://willemjiang.blogspot.com (English)
> > http://jnn.iteye.com (Chinese)
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> >
> >
> > On January 19, 2016 at 11:54:39 PM, Walzer, Thomas (thomas.walzer@integratix.net)
> wrote:
> >> Hi,
> >>
> >> camel-2.15.2
> >>
> >> I can successfully send to a HL7-Server, however I have troubles accessing the resulting
> >> ACK.
> >> Unfortunately it is of type UnpooledUnsafeDirectByteBuf and type conversion to
> string
> >> fails:
> >>
> >> ....On delivery attempt: 2 caught: org.apache.camel.TypeConversionException:
> >> Error during type conversion from type: java.lang.String to the required type: java.lang.String
> >> with value UnpooledUnsafeDirectByteBuf(freed) due io.netty.util.IllegalReferenceCountException:
> >> refCnt: 0
> >>
> >> Any ideas how to work with the ACK (besides logging which works)?
> >>
> >> Cheers, Thomas.
> >>
> >
>
>
Re: HL7/netty4/BodyType: io.netty.buffer.UnpooledUnsafeDirectByteBuf
Posted by "Walzer, Thomas" <th...@integratix.net>.
I tried <convertBodyTo type=„java.lang.String“>. If I try that:
...invalidpayloadexception: no body available of type: java.lang.String but has value: UnpooledUnsafeDirectByteBuf(freed) of type: io.netty.buffer.UnpooledUnsafeDirectByteBuf on...
I am sorry, logging does and did not really work. I had many headers that looked like the body. The body is of type UnpooledUnsafeDirectByteBuf. It does not show with the log-component. And it does not show using the log eip.
Cheers, Thomas.
> Am 20.01.2016 um 11:27 schrieb Willem Jiang <wi...@gmail.com>:
>
> Can you just turn the message into String before logging it?
> It looks like the UnpooledUnsafeDirectByteBuf is consumed.
>
> --
> Willem Jiang
>
>
> Blog: http://willemjiang.blogspot.com (English)
> http://jnn.iteye.com (Chinese)
> Twitter: willemjiang
> Weibo: 姜宁willem
>
>
>
> On January 19, 2016 at 11:54:39 PM, Walzer, Thomas (thomas.walzer@integratix.net) wrote:
>> Hi,
>>
>> camel-2.15.2
>>
>> I can successfully send to a HL7-Server, however I have troubles accessing the resulting
>> ACK.
>> Unfortunately it is of type UnpooledUnsafeDirectByteBuf and type conversion to string
>> fails:
>>
>> ....On delivery attempt: 2 caught: org.apache.camel.TypeConversionException:
>> Error during type conversion from type: java.lang.String to the required type: java.lang.String
>> with value UnpooledUnsafeDirectByteBuf(freed) due io.netty.util.IllegalReferenceCountException:
>> refCnt: 0
>>
>> Any ideas how to work with the ACK (besides logging which works)?
>>
>> Cheers, Thomas.
>>
>
Re: HL7/netty4/BodyType:
io.netty.buffer.UnpooledUnsafeDirectByteBuf
Posted by Willem Jiang <wi...@gmail.com>.
Can you just turn the message into String before logging it?
It looks like the UnpooledUnsafeDirectByteBuf is consumed.
--
Willem Jiang
Blog: http://willemjiang.blogspot.com (English)
http://jnn.iteye.com (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On January 19, 2016 at 11:54:39 PM, Walzer, Thomas (thomas.walzer@integratix.net) wrote:
> Hi,
>
> camel-2.15.2
>
> I can successfully send to a HL7-Server, however I have troubles accessing the resulting
> ACK.
> Unfortunately it is of type UnpooledUnsafeDirectByteBuf and type conversion to string
> fails:
>
> ....On delivery attempt: 2 caught: org.apache.camel.TypeConversionException:
> Error during type conversion from type: java.lang.String to the required type: java.lang.String
> with value UnpooledUnsafeDirectByteBuf(freed) due io.netty.util.IllegalReferenceCountException:
> refCnt: 0
>
> Any ideas how to work with the ACK (besides logging which works)?
>
> Cheers, Thomas.
>
Re: HL7/netty4/BodyType: io.netty.buffer.UnpooledUnsafeDirectByteBuf
Posted by "Walzer, Thomas" <th...@integratix.net>.
This was definitely a PEBKAC problem.
I was missing the decoder= part in the netty4 configuration. So the response never got decoded to something meaningful.
Sorry for bothering you all and being completely blind. Claus & Willem I owe you at least one beer.
Cheers, Thomas.
Am 24.01.2016 um 12:11 schrieb Claus Ibsen <cl...@gmail.com>>:
The HL7 message may contains some characters that causes the logger to
not log the message. (eg the pipes and other control chars it may
contain).
I can see the same on adding some logging to the camel-hl7 unit tests.
So that may be why your "log ${body}" do not print anything.
On Sun, Jan 24, 2016 at 11:13 AM, Walzer, Thomas
<th...@integratix.net>> wrote:
I am using Camel 2.15.2 & blueprint.
When using to uri=„log:…“ (Log component) it shows the body-type as unpooledunsafedirectbytebuf. This statement works ok. And yes, it should contain the ack response.
When using <log message=„*** ${body} ***“/> (or anything else that needs a string, like convertbodytostring, etc) I get exceptions.
Even when the first statement after netty4 is to-file it does not work. So there should be no one consuming it before.
The codecs are default.
<bean id="hl7nettydecoder" class="org.apache.camel.component.hl7.HL7MLLPNettyDecoderFactory">
</bean>
<bean id="hl7nettyencoder" class="org.apache.camel.component.hl7.HL7MLLPNettyEncoderFactory">
</bean>
I will continue to strip my complex project down.
Cheers, Thomas.
Am 22.01.2016 um 16:04 schrieb Claus Ibsen <cl...@gmail.com>>:
On Fri, Jan 22, 2016 at 3:58 PM, Walzer, Thomas
<th...@integratix.net>> wrote:
Problem is: I have a simple example that works fine. My more elaborate version breaks. But basically it is:
queue->transacted->convertbodytostring->setSomeHeaders->log->netty4->log
The netty4 listening to my message gets the message and returns an ack. When I try to get it as a string—>it breaks.
I do have a DefaultErrorhandler configured. But it should not kick in if everything works ok.
Just to be clear. Its that last part
netty4->log
Where you attempt to log the netty4 response (eg the ack response) ?
Do you use any special codec or encoders with netty4 or something?
And what version of Camel do you use?
When I change the netty4 endpoint to mina2 -> it works. So I assume the problem lies with the netty4 component. Maybe the codecs? Why do I not use mina2? Because ultimately I want TLS which is broken with mina2 in my version of Camel.
It seems like some problem with redelivery as Claus suggested, however I am still puzzled…
Cheers, Thomas.
Am 22.01.2016 um 08:20 schrieb Claus Ibsen <cl...@gmail.com>>:
On Tue, Jan 19, 2016 at 4:54 PM, Walzer, Thomas
<th...@integratix.net>> wrote:
Hi,
camel-2.15.2
I can successfully send to a HL7-Server, however I have troubles accessing the resulting ACK.
Unfortunately it is of type UnpooledUnsafeDirectByteBuf and type conversion to string fails:
....On delivery attempt: 2 caught: org.apache.camel.TypeConversionException: Error during type conversion from type: java.lang.String to the required type: java.lang.String with value UnpooledUnsafeDirectByteBuf(freed) due io.netty.util.IllegalReferenceCountException: refCnt: 0
Sounds like you are doing redelivery and the byte buf is not reset on
redelivery or something so the data stream becomes empty and not
convertable to a string type. A bit like when you are not using stream
caching
http://camel.apache.org/why-is-my-message-body-empty.html
Any ideas how to work with the ACK (besides logging which works)?
Cheers, Thomas.
--
Claus Ibsen
-----------------
http://davsclaus.com<http://davsclaus.com/> @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
--
Claus Ibsen
-----------------
http://davsclaus.com<http://davsclaus.com/> @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
--
Claus Ibsen
-----------------
http://davsclaus.com<http://davsclaus.com/> @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: HL7/netty4/BodyType: io.netty.buffer.UnpooledUnsafeDirectByteBuf
Posted by Claus Ibsen <cl...@gmail.com>.
The HL7 message may contains some characters that causes the logger to
not log the message. (eg the pipes and other control chars it may
contain).
I can see the same on adding some logging to the camel-hl7 unit tests.
So that may be why your "log ${body}" do not print anything.
On Sun, Jan 24, 2016 at 11:13 AM, Walzer, Thomas
<th...@integratix.net> wrote:
> I am using Camel 2.15.2 & blueprint.
> When using to uri=„log:…“ (Log component) it shows the body-type as unpooledunsafedirectbytebuf. This statement works ok. And yes, it should contain the ack response.
> When using <log message=„*** ${body} ***“/> (or anything else that needs a string, like convertbodytostring, etc) I get exceptions.
> Even when the first statement after netty4 is to-file it does not work. So there should be no one consuming it before.
> The codecs are default.
>
>
> <bean id="hl7nettydecoder" class="org.apache.camel.component.hl7.HL7MLLPNettyDecoderFactory">
> </bean>
> <bean id="hl7nettyencoder" class="org.apache.camel.component.hl7.HL7MLLPNettyEncoderFactory">
> </bean>
>
> I will continue to strip my complex project down.
>
> Cheers, Thomas.
>
> Am 22.01.2016 um 16:04 schrieb Claus Ibsen <cl...@gmail.com>>:
>
> On Fri, Jan 22, 2016 at 3:58 PM, Walzer, Thomas
> <th...@integratix.net>> wrote:
> Problem is: I have a simple example that works fine. My more elaborate version breaks. But basically it is:
> queue->transacted->convertbodytostring->setSomeHeaders->log->netty4->log
>
> The netty4 listening to my message gets the message and returns an ack. When I try to get it as a string—>it breaks.
> I do have a DefaultErrorhandler configured. But it should not kick in if everything works ok.
>
>
> Just to be clear. Its that last part
>
> netty4->log
>
> Where you attempt to log the netty4 response (eg the ack response) ?
>
> Do you use any special codec or encoders with netty4 or something?
> And what version of Camel do you use?
>
> When I change the netty4 endpoint to mina2 -> it works. So I assume the problem lies with the netty4 component. Maybe the codecs? Why do I not use mina2? Because ultimately I want TLS which is broken with mina2 in my version of Camel.
>
> It seems like some problem with redelivery as Claus suggested, however I am still puzzled…
>
> Cheers, Thomas.
>
> Am 22.01.2016 um 08:20 schrieb Claus Ibsen <cl...@gmail.com>>:
>
> On Tue, Jan 19, 2016 at 4:54 PM, Walzer, Thomas
> <th...@integratix.net>> wrote:
> Hi,
>
> camel-2.15.2
>
> I can successfully send to a HL7-Server, however I have troubles accessing the resulting ACK.
> Unfortunately it is of type UnpooledUnsafeDirectByteBuf and type conversion to string fails:
>
> ....On delivery attempt: 2 caught: org.apache.camel.TypeConversionException: Error during type conversion from type: java.lang.String to the required type: java.lang.String with value UnpooledUnsafeDirectByteBuf(freed) due io.netty.util.IllegalReferenceCountException: refCnt: 0
>
>
> Sounds like you are doing redelivery and the byte buf is not reset on
> redelivery or something so the data stream becomes empty and not
> convertable to a string type. A bit like when you are not using stream
> caching
> http://camel.apache.org/why-is-my-message-body-empty.html
>
>
>
> Any ideas how to work with the ACK (besides logging which works)?
>
> Cheers, Thomas.
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com<http://davsclaus.com/> @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: HL7/netty4/BodyType: io.netty.buffer.UnpooledUnsafeDirectByteBuf
Posted by "Walzer, Thomas" <th...@integratix.net>.
I am using Camel 2.15.2 & blueprint.
When using to uri=„log:…“ (Log component) it shows the body-type as unpooledunsafedirectbytebuf. This statement works ok. And yes, it should contain the ack response.
When using <log message=„*** ${body} ***“/> (or anything else that needs a string, like convertbodytostring, etc) I get exceptions.
Even when the first statement after netty4 is to-file it does not work. So there should be no one consuming it before.
The codecs are default.
<bean id="hl7nettydecoder" class="org.apache.camel.component.hl7.HL7MLLPNettyDecoderFactory">
</bean>
<bean id="hl7nettyencoder" class="org.apache.camel.component.hl7.HL7MLLPNettyEncoderFactory">
</bean>
I will continue to strip my complex project down.
Cheers, Thomas.
Am 22.01.2016 um 16:04 schrieb Claus Ibsen <cl...@gmail.com>>:
On Fri, Jan 22, 2016 at 3:58 PM, Walzer, Thomas
<th...@integratix.net>> wrote:
Problem is: I have a simple example that works fine. My more elaborate version breaks. But basically it is:
queue->transacted->convertbodytostring->setSomeHeaders->log->netty4->log
The netty4 listening to my message gets the message and returns an ack. When I try to get it as a string—>it breaks.
I do have a DefaultErrorhandler configured. But it should not kick in if everything works ok.
Just to be clear. Its that last part
netty4->log
Where you attempt to log the netty4 response (eg the ack response) ?
Do you use any special codec or encoders with netty4 or something?
And what version of Camel do you use?
When I change the netty4 endpoint to mina2 -> it works. So I assume the problem lies with the netty4 component. Maybe the codecs? Why do I not use mina2? Because ultimately I want TLS which is broken with mina2 in my version of Camel.
It seems like some problem with redelivery as Claus suggested, however I am still puzzled…
Cheers, Thomas.
Am 22.01.2016 um 08:20 schrieb Claus Ibsen <cl...@gmail.com>>:
On Tue, Jan 19, 2016 at 4:54 PM, Walzer, Thomas
<th...@integratix.net>> wrote:
Hi,
camel-2.15.2
I can successfully send to a HL7-Server, however I have troubles accessing the resulting ACK.
Unfortunately it is of type UnpooledUnsafeDirectByteBuf and type conversion to string fails:
....On delivery attempt: 2 caught: org.apache.camel.TypeConversionException: Error during type conversion from type: java.lang.String to the required type: java.lang.String with value UnpooledUnsafeDirectByteBuf(freed) due io.netty.util.IllegalReferenceCountException: refCnt: 0
Sounds like you are doing redelivery and the byte buf is not reset on
redelivery or something so the data stream becomes empty and not
convertable to a string type. A bit like when you are not using stream
caching
http://camel.apache.org/why-is-my-message-body-empty.html
Any ideas how to work with the ACK (besides logging which works)?
Cheers, Thomas.
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
--
Claus Ibsen
-----------------
http://davsclaus.com<http://davsclaus.com/> @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: HL7/netty4/BodyType: io.netty.buffer.UnpooledUnsafeDirectByteBuf
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Jan 22, 2016 at 3:58 PM, Walzer, Thomas
<th...@integratix.net> wrote:
> Problem is: I have a simple example that works fine. My more elaborate version breaks. But basically it is:
> queue->transacted->convertbodytostring->setSomeHeaders->log->netty4->log
>
> The netty4 listening to my message gets the message and returns an ack. When I try to get it as a string—>it breaks.
> I do have a DefaultErrorhandler configured. But it should not kick in if everything works ok.
>
Just to be clear. Its that last part
netty4->log
Where you attempt to log the netty4 response (eg the ack response) ?
Do you use any special codec or encoders with netty4 or something?
And what version of Camel do you use?
> When I change the netty4 endpoint to mina2 -> it works. So I assume the problem lies with the netty4 component. Maybe the codecs? Why do I not use mina2? Because ultimately I want TLS which is broken with mina2 in my version of Camel.
>
> It seems like some problem with redelivery as Claus suggested, however I am still puzzled…
>
> Cheers, Thomas.
>
>> Am 22.01.2016 um 08:20 schrieb Claus Ibsen <cl...@gmail.com>:
>>
>> On Tue, Jan 19, 2016 at 4:54 PM, Walzer, Thomas
>> <th...@integratix.net> wrote:
>>> Hi,
>>>
>>> camel-2.15.2
>>>
>>> I can successfully send to a HL7-Server, however I have troubles accessing the resulting ACK.
>>> Unfortunately it is of type UnpooledUnsafeDirectByteBuf and type conversion to string fails:
>>>
>>> ....On delivery attempt: 2 caught: org.apache.camel.TypeConversionException: Error during type conversion from type: java.lang.String to the required type: java.lang.String with value UnpooledUnsafeDirectByteBuf(freed) due io.netty.util.IllegalReferenceCountException: refCnt: 0
>>>
>>
>> Sounds like you are doing redelivery and the byte buf is not reset on
>> redelivery or something so the data stream becomes empty and not
>> convertable to a string type. A bit like when you are not using stream
>> caching
>> http://camel.apache.org/why-is-my-message-body-empty.html
>>
>>
>>
>>> Any ideas how to work with the ACK (besides logging which works)?
>>>
>>> Cheers, Thomas.
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: HL7/netty4/BodyType: io.netty.buffer.UnpooledUnsafeDirectByteBuf
Posted by "Walzer, Thomas" <th...@integratix.net>.
Problem is: I have a simple example that works fine. My more elaborate version breaks. But basically it is:
queue->transacted->convertbodytostring->setSomeHeaders->log->netty4->log
The netty4 listening to my message gets the message and returns an ack. When I try to get it as a string—>it breaks.
I do have a DefaultErrorhandler configured. But it should not kick in if everything works ok.
When I change the netty4 endpoint to mina2 -> it works. So I assume the problem lies with the netty4 component. Maybe the codecs? Why do I not use mina2? Because ultimately I want TLS which is broken with mina2 in my version of Camel.
It seems like some problem with redelivery as Claus suggested, however I am still puzzled…
Cheers, Thomas.
> Am 22.01.2016 um 08:20 schrieb Claus Ibsen <cl...@gmail.com>:
>
> On Tue, Jan 19, 2016 at 4:54 PM, Walzer, Thomas
> <th...@integratix.net> wrote:
>> Hi,
>>
>> camel-2.15.2
>>
>> I can successfully send to a HL7-Server, however I have troubles accessing the resulting ACK.
>> Unfortunately it is of type UnpooledUnsafeDirectByteBuf and type conversion to string fails:
>>
>> ....On delivery attempt: 2 caught: org.apache.camel.TypeConversionException: Error during type conversion from type: java.lang.String to the required type: java.lang.String with value UnpooledUnsafeDirectByteBuf(freed) due io.netty.util.IllegalReferenceCountException: refCnt: 0
>>
>
> Sounds like you are doing redelivery and the byte buf is not reset on
> redelivery or something so the data stream becomes empty and not
> convertable to a string type. A bit like when you are not using stream
> caching
> http://camel.apache.org/why-is-my-message-body-empty.html
>
>
>
>> Any ideas how to work with the ACK (besides logging which works)?
>>
>> Cheers, Thomas.
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
Re: HL7/netty4/BodyType: io.netty.buffer.UnpooledUnsafeDirectByteBuf
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Jan 19, 2016 at 4:54 PM, Walzer, Thomas
<th...@integratix.net> wrote:
> Hi,
>
> camel-2.15.2
>
> I can successfully send to a HL7-Server, however I have troubles accessing the resulting ACK.
> Unfortunately it is of type UnpooledUnsafeDirectByteBuf and type conversion to string fails:
>
> ....On delivery attempt: 2 caught: org.apache.camel.TypeConversionException: Error during type conversion from type: java.lang.String to the required type: java.lang.String with value UnpooledUnsafeDirectByteBuf(freed) due io.netty.util.IllegalReferenceCountException: refCnt: 0
>
Sounds like you are doing redelivery and the byte buf is not reset on
redelivery or something so the data stream becomes empty and not
convertable to a string type. A bit like when you are not using stream
caching
http://camel.apache.org/why-is-my-message-body-empty.html
> Any ideas how to work with the ACK (besides logging which works)?
>
> Cheers, Thomas.
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2