> 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:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > > 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 <[EMAIL PROTECTED]> wrote: > > On 05/11/2008, Oghie Sheehy <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > > > > > > 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > ********************************************************************** > > > > > > 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: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
