You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jmeter-dev@jakarta.apache.org by sebb <se...@gmail.com> on 2008/11/04 21:16:45 UTC
Re: FW: TCP Sampler Extension to support length-prefixed binary data
On 17/10/2008, Oghie Sheehy <os...@fexcodcc.com> wrote:
> Thanks, have created enhancement bug 46030 and attached source to it.
>
I've just started looking at the code. Looks good, but there are a
couple of areas which I think need tweaking.
BinaryTCPClientImpl uses eolByte which is set from the property tcp.eolByte.
I'm not sure that this is needed - does it make sense for a binary
protocol to have an End of Line byte? If so, then the property name
needs to be changed, otherwise one cannot mix TCP implementations in a
test plan.
I'm not entirely sure why LengthPrefixedBinaryTCPClientImpl does not
extend BinaryTCPClientImpl instead of decorating it?
<snip>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
RE: FW: TCP Sampler Extension to support length-prefixed binary data
Posted by Oghie Sheehy <os...@fexcodcc.com>.
> OK. Let me know if there are any problems.
Will do, may not be for a couple of weeks. Have run a quick test myself using an existing testplan and looks good.
> I found I had to make another change - the length-prefixed client has
> to assume that the body will be received without EOM checking, so I
> added a way to reset the value. However, this won't affect the
> behaviour unless the property is set.
Makes sense, thanks.
-----Original Message-----
From: sebb [mailto:sebbaz@gmail.com]
Sent: 06 November 2008 13:31
To: JMeter Developers List
Cc: Mike Cronin
Subject: Re: FW: TCP Sampler Extension to support length-prefixed binary
data
OK. Let me know if there are any problems.
I found I had to make another change - the length-prefixed client has
to assume that the body will be received without EOM checking, so I
added a way to reset the value. However, this won't affect the
behaviour unless the property is set.
On 06/11/2008, Oghie Sheehy <os...@fexcodcc.com> wrote:
> > OK, I think it is now ready. If you want to test it, it is in nightly
> > builds from r711667.
>
>
> Thanks, we are just about to start a test cycle and will use the latest build.
>
>
> -----Original Message-----
> From: sebb [mailto:sebbaz@gmail.com]
>
> Sent: 05 November 2008 21:52
> To: JMeter Developers List
> Subject: Re: FW: TCP Sampler Extension to support length-prefixed binary
> data
>
>
> On 05/11/2008, sebb <se...@gmail.com> wrote:
> > On 05/11/2008, Oghie Sheehy <os...@fexcodcc.com> wrote:
> > > > I've just started looking at the code. Looks good, but there are a
> > > > couple of areas which I think need tweaking.
> > >
> > > > BinaryTCPClientImpl uses eolByte which is set from the property tcp.eolByte.
> > > > I'm not sure that this is needed - does it make sense for a binary
> > > > protocol to have an End of Line byte? If so, then the property name
> > > > needs to be changed, otherwise one cannot mix TCP implementations in a
> > > > test plan.
> > >
> > > Yes, eol does not make sense in a binary protocol but I think an end of message byte would. So the property name would need to be changed.
> > >
> >
> >
> > OK, I'll do that.
> > The eolByte methods are part of the interface so the name cannot be changed,
> > but I will update the Javadoc.
> >
> >
> > >
> > > > I'm not entirely sure why LengthPrefixedBinaryTCPClientImpl does not
> > > > extend BinaryTCPClientImpl instead of decorating it?
> > >
> > > General idea was that the length prefixing would be independent of protocol data to allow binary length followed by character data and character length followed by character data. This was why length prefix handling methods were left in the decorator rather than in a direct subclass. Probably unnecessary and no problem if it becomes a direct subclass.
> > >
> >
> >
> > OK, understood. I'll add a bit more to the Javadoc.
> >
> > I've added the initial implementations of the code to SVN, and will
> > now work on the fixes mentioned above.
> >
>
> OK, I think it is now ready. If you want to test it, it is in nightly
> builds from r711667.
>
> >
> > >
> > >
> > > -----Original Message-----
> > > From: sebb [mailto:sebbaz@gmail.com]
> > >
> > > Sent: 04 November 2008 20:17
> > > To: JMeter Developers List
> > > Subject: Re: FW: TCP Sampler Extension to support length-prefixed binary
> > > data
> > >
> > >
> > >
> > > On 17/10/2008, Oghie Sheehy <os...@fexcodcc.com> wrote:
> > > > Thanks, have created enhancement bug 46030 and attached source to it.
> > > >
> > >
> > > I've just started looking at the code. Looks good, but there are a
> > > couple of areas which I think need tweaking.
> > >
> > > BinaryTCPClientImpl uses eolByte which is set from the property tcp.eolByte.
> > > I'm not sure that this is needed - does it make sense for a binary
> > > protocol to have an End of Line byte? If so, then the property name
> > > needs to be changed, otherwise one cannot mix TCP implementations in a
> > > test plan.
> > >
> > > I'm not entirely sure why LengthPrefixedBinaryTCPClientImpl does not
> > > extend BinaryTCPClientImpl instead of decorating it?
> > >
> > > <snip>
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> > >
> > > **********************************************************************
> > >
> > > E-mail disclaimer
> > > FEXCO Dynamic Currency Conversion Limited, registered in Ireland, No. 246289. Registered Office: FEXCO Centre, Iveragh Road, Killorglin, Co. Kerry.
> > >
> > > This message, including any attachments, is confidential. If you are not the named recipient, please contact the sender and delete the email from your system.
> > >
> > > **********************************************************************
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: FW: TCP Sampler Extension to support length-prefixed binary data
Posted by sebb <se...@gmail.com>.
OK. Let me know if there are any problems.
I found I had to make another change - the length-prefixed client has
to assume that the body will be received without EOM checking, so I
added a way to reset the value. However, this won't affect the
behaviour unless the property is set.
On 06/11/2008, Oghie Sheehy <os...@fexcodcc.com> wrote:
> > OK, I think it is now ready. If you want to test it, it is in nightly
> > builds from r711667.
>
>
> Thanks, we are just about to start a test cycle and will use the latest build.
>
>
> -----Original Message-----
> From: sebb [mailto:sebbaz@gmail.com]
>
> Sent: 05 November 2008 21:52
> To: JMeter Developers List
> Subject: Re: FW: TCP Sampler Extension to support length-prefixed binary
> data
>
>
> On 05/11/2008, sebb <se...@gmail.com> wrote:
> > On 05/11/2008, Oghie Sheehy <os...@fexcodcc.com> wrote:
> > > > I've just started looking at the code. Looks good, but there are a
> > > > couple of areas which I think need tweaking.
> > >
> > > > BinaryTCPClientImpl uses eolByte which is set from the property tcp.eolByte.
> > > > I'm not sure that this is needed - does it make sense for a binary
> > > > protocol to have an End of Line byte? If so, then the property name
> > > > needs to be changed, otherwise one cannot mix TCP implementations in a
> > > > test plan.
> > >
> > > Yes, eol does not make sense in a binary protocol but I think an end of message byte would. So the property name would need to be changed.
> > >
> >
> >
> > OK, I'll do that.
> > The eolByte methods are part of the interface so the name cannot be changed,
> > but I will update the Javadoc.
> >
> >
> > >
> > > > I'm not entirely sure why LengthPrefixedBinaryTCPClientImpl does not
> > > > extend BinaryTCPClientImpl instead of decorating it?
> > >
> > > General idea was that the length prefixing would be independent of protocol data to allow binary length followed by character data and character length followed by character data. This was why length prefix handling methods were left in the decorator rather than in a direct subclass. Probably unnecessary and no problem if it becomes a direct subclass.
> > >
> >
> >
> > OK, understood. I'll add a bit more to the Javadoc.
> >
> > I've added the initial implementations of the code to SVN, and will
> > now work on the fixes mentioned above.
> >
>
> OK, I think it is now ready. If you want to test it, it is in nightly
> builds from r711667.
>
> >
> > >
> > >
> > > -----Original Message-----
> > > From: sebb [mailto:sebbaz@gmail.com]
> > >
> > > Sent: 04 November 2008 20:17
> > > To: JMeter Developers List
> > > Subject: Re: FW: TCP Sampler Extension to support length-prefixed binary
> > > data
> > >
> > >
> > >
> > > On 17/10/2008, Oghie Sheehy <os...@fexcodcc.com> wrote:
> > > > Thanks, have created enhancement bug 46030 and attached source to it.
> > > >
> > >
> > > I've just started looking at the code. Looks good, but there are a
> > > couple of areas which I think need tweaking.
> > >
> > > BinaryTCPClientImpl uses eolByte which is set from the property tcp.eolByte.
> > > I'm not sure that this is needed - does it make sense for a binary
> > > protocol to have an End of Line byte? If so, then the property name
> > > needs to be changed, otherwise one cannot mix TCP implementations in a
> > > test plan.
> > >
> > > I'm not entirely sure why LengthPrefixedBinaryTCPClientImpl does not
> > > extend BinaryTCPClientImpl instead of decorating it?
> > >
> > > <snip>
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> > >
> > > **********************************************************************
> > >
> > > E-mail disclaimer
> > > FEXCO Dynamic Currency Conversion Limited, registered in Ireland, No. 246289. Registered Office: FEXCO Centre, Iveragh Road, Killorglin, Co. Kerry.
> > >
> > > This message, including any attachments, is confidential. If you are not the named recipient, please contact the sender and delete the email from your system.
> > >
> > > **********************************************************************
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
RE: FW: TCP Sampler Extension to support length-prefixed binary data
Posted by Oghie Sheehy <os...@fexcodcc.com>.
> OK, I think it is now ready. If you want to test it, it is in nightly
> builds from r711667.
Thanks, we are just about to start a test cycle and will use the latest build.
-----Original Message-----
From: sebb [mailto:sebbaz@gmail.com]
Sent: 05 November 2008 21:52
To: JMeter Developers List
Subject: Re: FW: TCP Sampler Extension to support length-prefixed binary
data
On 05/11/2008, sebb <se...@gmail.com> wrote:
> On 05/11/2008, Oghie Sheehy <os...@fexcodcc.com> wrote:
> > > I've just started looking at the code. Looks good, but there are a
> > > couple of areas which I think need tweaking.
> >
> > > BinaryTCPClientImpl uses eolByte which is set from the property tcp.eolByte.
> > > I'm not sure that this is needed - does it make sense for a binary
> > > protocol to have an End of Line byte? If so, then the property name
> > > needs to be changed, otherwise one cannot mix TCP implementations in a
> > > test plan.
> >
> > Yes, eol does not make sense in a binary protocol but I think an end of message byte would. So the property name would need to be changed.
> >
>
>
> OK, I'll do that.
> The eolByte methods are part of the interface so the name cannot be changed,
> but I will update the Javadoc.
>
>
> >
> > > I'm not entirely sure why LengthPrefixedBinaryTCPClientImpl does not
> > > extend BinaryTCPClientImpl instead of decorating it?
> >
> > General idea was that the length prefixing would be independent of protocol data to allow binary length followed by character data and character length followed by character data. This was why length prefix handling methods were left in the decorator rather than in a direct subclass. Probably unnecessary and no problem if it becomes a direct subclass.
> >
>
>
> OK, understood. I'll add a bit more to the Javadoc.
>
> I've added the initial implementations of the code to SVN, and will
> now work on the fixes mentioned above.
>
OK, I think it is now ready. If you want to test it, it is in nightly
builds from r711667.
>
> >
> >
> > -----Original Message-----
> > From: sebb [mailto:sebbaz@gmail.com]
> >
> > Sent: 04 November 2008 20:17
> > To: JMeter Developers List
> > Subject: Re: FW: TCP Sampler Extension to support length-prefixed binary
> > data
> >
> >
> >
> > On 17/10/2008, Oghie Sheehy <os...@fexcodcc.com> wrote:
> > > Thanks, have created enhancement bug 46030 and attached source to it.
> > >
> >
> > I've just started looking at the code. Looks good, but there are a
> > couple of areas which I think need tweaking.
> >
> > BinaryTCPClientImpl uses eolByte which is set from the property tcp.eolByte.
> > I'm not sure that this is needed - does it make sense for a binary
> > protocol to have an End of Line byte? If so, then the property name
> > needs to be changed, otherwise one cannot mix TCP implementations in a
> > test plan.
> >
> > I'm not entirely sure why LengthPrefixedBinaryTCPClientImpl does not
> > extend BinaryTCPClientImpl instead of decorating it?
> >
> > <snip>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
> >
> > **********************************************************************
> >
> > E-mail disclaimer
> > FEXCO Dynamic Currency Conversion Limited, registered in Ireland, No. 246289. Registered Office: FEXCO Centre, Iveragh Road, Killorglin, Co. Kerry.
> >
> > This message, including any attachments, is confidential. If you are not the named recipient, please contact the sender and delete the email from your system.
> >
> > **********************************************************************
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: FW: TCP Sampler Extension to support length-prefixed binary data
Posted by sebb <se...@gmail.com>.
On 05/11/2008, sebb <se...@gmail.com> wrote:
> On 05/11/2008, Oghie Sheehy <os...@fexcodcc.com> wrote:
> > > I've just started looking at the code. Looks good, but there are a
> > > couple of areas which I think need tweaking.
> >
> > > BinaryTCPClientImpl uses eolByte which is set from the property tcp.eolByte.
> > > I'm not sure that this is needed - does it make sense for a binary
> > > protocol to have an End of Line byte? If so, then the property name
> > > needs to be changed, otherwise one cannot mix TCP implementations in a
> > > test plan.
> >
> > Yes, eol does not make sense in a binary protocol but I think an end of message byte would. So the property name would need to be changed.
> >
>
>
> OK, I'll do that.
> The eolByte methods are part of the interface so the name cannot be changed,
> but I will update the Javadoc.
>
>
> >
> > > I'm not entirely sure why LengthPrefixedBinaryTCPClientImpl does not
> > > extend BinaryTCPClientImpl instead of decorating it?
> >
> > General idea was that the length prefixing would be independent of protocol data to allow binary length followed by character data and character length followed by character data. This was why length prefix handling methods were left in the decorator rather than in a direct subclass. Probably unnecessary and no problem if it becomes a direct subclass.
> >
>
>
> OK, understood. I'll add a bit more to the Javadoc.
>
> I've added the initial implementations of the code to SVN, and will
> now work on the fixes mentioned above.
>
OK, I think it is now ready. If you want to test it, it is in nightly
builds from r711667.
>
> >
> >
> > -----Original Message-----
> > From: sebb [mailto:sebbaz@gmail.com]
> >
> > Sent: 04 November 2008 20:17
> > To: JMeter Developers List
> > Subject: Re: FW: TCP Sampler Extension to support length-prefixed binary
> > data
> >
> >
> >
> > On 17/10/2008, Oghie Sheehy <os...@fexcodcc.com> wrote:
> > > Thanks, have created enhancement bug 46030 and attached source to it.
> > >
> >
> > I've just started looking at the code. Looks good, but there are a
> > couple of areas which I think need tweaking.
> >
> > BinaryTCPClientImpl uses eolByte which is set from the property tcp.eolByte.
> > I'm not sure that this is needed - does it make sense for a binary
> > protocol to have an End of Line byte? If so, then the property name
> > needs to be changed, otherwise one cannot mix TCP implementations in a
> > test plan.
> >
> > I'm not entirely sure why LengthPrefixedBinaryTCPClientImpl does not
> > extend BinaryTCPClientImpl instead of decorating it?
> >
> > <snip>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
> >
> > **********************************************************************
> >
> > E-mail disclaimer
> > FEXCO Dynamic Currency Conversion Limited, registered in Ireland, No. 246289. Registered Office: FEXCO Centre, Iveragh Road, Killorglin, Co. Kerry.
> >
> > This message, including any attachments, is confidential. If you are not the named recipient, please contact the sender and delete the email from your system.
> >
> > **********************************************************************
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: FW: TCP Sampler Extension to support length-prefixed binary data
Posted by sebb <se...@gmail.com>.
On 05/11/2008, Oghie Sheehy <os...@fexcodcc.com> wrote:
> > I've just started looking at the code. Looks good, but there are a
> > couple of areas which I think need tweaking.
>
> > BinaryTCPClientImpl uses eolByte which is set from the property tcp.eolByte.
> > I'm not sure that this is needed - does it make sense for a binary
> > protocol to have an End of Line byte? If so, then the property name
> > needs to be changed, otherwise one cannot mix TCP implementations in a
> > test plan.
>
> Yes, eol does not make sense in a binary protocol but I think an end of message byte would. So the property name would need to be changed.
>
OK, I'll do that.
The eolByte methods are part of the interface so the name cannot be changed,
but I will update the Javadoc.
>
> > I'm not entirely sure why LengthPrefixedBinaryTCPClientImpl does not
> > extend BinaryTCPClientImpl instead of decorating it?
>
> General idea was that the length prefixing would be independent of protocol data to allow binary length followed by character data and character length followed by character data. This was why length prefix handling methods were left in the decorator rather than in a direct subclass. Probably unnecessary and no problem if it becomes a direct subclass.
>
OK, understood. I'll add a bit more to the Javadoc.
I've added the initial implementations of the code to SVN, and will
now work on the fixes mentioned above.
>
>
> -----Original Message-----
> From: sebb [mailto:sebbaz@gmail.com]
>
> Sent: 04 November 2008 20:17
> To: JMeter Developers List
> Subject: Re: FW: TCP Sampler Extension to support length-prefixed binary
> data
>
>
>
> On 17/10/2008, Oghie Sheehy <os...@fexcodcc.com> wrote:
> > Thanks, have created enhancement bug 46030 and attached source to it.
> >
>
> I've just started looking at the code. Looks good, but there are a
> couple of areas which I think need tweaking.
>
> BinaryTCPClientImpl uses eolByte which is set from the property tcp.eolByte.
> I'm not sure that this is needed - does it make sense for a binary
> protocol to have an End of Line byte? If so, then the property name
> needs to be changed, otherwise one cannot mix TCP implementations in a
> test plan.
>
> I'm not entirely sure why LengthPrefixedBinaryTCPClientImpl does not
> extend BinaryTCPClientImpl instead of decorating it?
>
> <snip>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
>
> **********************************************************************
>
> E-mail disclaimer
> FEXCO Dynamic Currency Conversion Limited, registered in Ireland, No. 246289. Registered Office: FEXCO Centre, Iveragh Road, Killorglin, Co. Kerry.
>
> This message, including any attachments, is confidential. If you are not the named recipient, please contact the sender and delete the email from your system.
>
> **********************************************************************
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
RE: FW: TCP Sampler Extension to support length-prefixed binary data
Posted by Oghie Sheehy <os...@fexcodcc.com>.
> I've just started looking at the code. Looks good, but there are a
> couple of areas which I think need tweaking.
> BinaryTCPClientImpl uses eolByte which is set from the property tcp.eolByte.
> I'm not sure that this is needed - does it make sense for a binary
> protocol to have an End of Line byte? If so, then the property name
> needs to be changed, otherwise one cannot mix TCP implementations in a
> test plan.
Yes, eol does not make sense in a binary protocol but I think an end of message byte would. So the property name would need to be changed.
> I'm not entirely sure why LengthPrefixedBinaryTCPClientImpl does not
> extend BinaryTCPClientImpl instead of decorating it?
General idea was that the length prefixing would be independent of protocol data to allow binary length followed by character data and character length followed by character data. This was why length prefix handling methods were left in the decorator rather than in a direct subclass. Probably unnecessary and no problem if it becomes a direct subclass.
-----Original Message-----
From: sebb [mailto:sebbaz@gmail.com]
Sent: 04 November 2008 20:17
To: JMeter Developers List
Subject: Re: FW: TCP Sampler Extension to support length-prefixed binary
data
On 17/10/2008, Oghie Sheehy <os...@fexcodcc.com> wrote:
> Thanks, have created enhancement bug 46030 and attached source to it.
>
I've just started looking at the code. Looks good, but there are a
couple of areas which I think need tweaking.
BinaryTCPClientImpl uses eolByte which is set from the property tcp.eolByte.
I'm not sure that this is needed - does it make sense for a binary
protocol to have an End of Line byte? If so, then the property name
needs to be changed, otherwise one cannot mix TCP implementations in a
test plan.
I'm not entirely sure why LengthPrefixedBinaryTCPClientImpl does not
extend BinaryTCPClientImpl instead of decorating it?
<snip>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
**********************************************************************
E-mail disclaimer
FEXCO Dynamic Currency Conversion Limited, registered in Ireland, No. 246289. Registered Office: FEXCO Centre, Iveragh Road, Killorglin, Co. Kerry.
This message, including any attachments, is confidential. If you are not the named recipient, please contact the sender and delete the email from your system.
**********************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org