Hi,
I agree that JMeter is the issue here, I have not really had much experience
with telnetting, but I will give it a go, or delegate to the tester here to
make sure that we can somehow test the responses.
Is there any examples out there is TCP client testing? I will go through the
unit tests now to check what we can do...
That timeout property will come in handy too! We need that to be
configurable so that our app closes client abandoned connections...
Cheers,
Mark
On Thu, Jul 24, 2008 at 11:14 AM, Jeanfrancois Arcand <
Jeanfrancois.Arcand_at_sun.com> wrote:
> Salut,
>
> Mark Macumber wrote:
>
>> Hi,
>>
>> Thanks for the tip, is this the same as doing:
>>
>> SelectableChannel selectableChannel = ctx.getSelectionKey().channel();
>> selectableChannel.close();
>>
>> ??
>>
>
> It is better to let the framework close the channel and recycle its
> internal object with the solution I'm proposing. It really do exactly what
> you have described.
>
>
>
>> Either way, we are really trying to work with keep-alive here, so closing
>> the connection will be great for testing the actual response sent, but thats
>> all, we need to make sure that we are also testing that the connection
>> doesn't close, but get the correct response.
>>
>
> I see. I think the problem is with JMeter. If you try to telnet the port
> (or use another client), does the client gets the response?
>
> You might also want to manipulate the idle time:
>
>
> ((DefaultSelectionKeyHandler)ctx.getSelectorHandler().getSelectionKeyHandler()).setTimeout(<<timeinMiliseconds>>);
>
> By default, we close idel to 30 seconds.
>
> A+
>
> -- Jeanfrancois
>
>
>
>
>
>
>> Cheers,
>> Mark
>>
>>
>> On Thu, Jul 24, 2008 at 11:02 AM, Jeanfrancois Arcand <
>> Jeanfrancois.Arcand_at_sun.com <mailto:Jeanfrancois.Arcand_at_sun.com>> wrote:
>>
>> Salut,
>>
>>
>> Mark Macumber wrote:
>>
>> Hello Jeanfrancois,
>>
>> Yes that is correct I believe we were using HTTP 1.0, so that
>> explains everything. :)
>>
>>
>> :-). Now an alternative solution is to set, inside your ProtocolFilter:
>>
>> Context.setKeyRegistrationState(Context.KeyRegistrationState.CANCEL);
>>
>> This will close the connection for you.
>>
>> A+
>>
>> -- Jeanfrancois
>>
>>
>>
>> Cheers,
>> Mark
>>
>>
>>
>> On Thu, Jul 24, 2008 at 10:49 AM, Jeanfrancois Arcand
>> <Jeanfrancois.Arcand_at_sun.com
>> <mailto:Jeanfrancois.Arcand_at_sun.com>
>> <mailto:Jeanfrancois.Arcand_at_sun.com
>> <mailto:Jeanfrancois.Arcand_at_sun.com>>> wrote:
>>
>> Salut,
>>
>>
>> Mark Macumber wrote:
>>
>> Hi John,
>>
>> So it appears that I may have been on the wrong track, I was
>> actually getting a response when I used,
>>
>> OutputWriter.flushChannel
>>
>> The miss-leading thing to me was that JMeter did not
>> /appear/ to
>> be getting a response because the connection was still
>> open, not
>> like with HTTP where the connection is closed...
>>
>> So, when I did this:
>>
>> SelectableChannel selectableChannel =
>> ctx.getSelectionKey().channel();
>> OutputWriter.flushChannel(selectableChannel,
>> messageResponse.getMessageData());
>> *selectableChannel.close();*
>>
>> I got an immediate "notification" (visual response) from
>> JMeter
>> that showed me that it received the bytes from my filter.
>>
>> If I removed the close() call and waited for approx. 30
>> seconds,
>> then I also got this response as (i guess) the connection
>> timed
>> out and closed itself...
>>
>>
>> Yes, this is the default time out when a connection is idle. It
>> seems to me that JMeter is waiting for the connection to be
>> closed....when you tested using HTTP, were you using HTTP
>> 1.0? With
>> 1.0, the connection are automatically closed, which I suspect
>> was
>> the behavior you were seeing.
>>
>> Thanks
>>
>> -- Jeanfrancois
>>
>>
>>
>> Cheers,
>> Mark
>>
>>
>> On Wed, Jul 23, 2008 at 5:02 PM, John ROM
>> <snake-john_at_gmx.de <mailto:snake-john_at_gmx.de>
>> <mailto:snake-john_at_gmx.de <mailto:snake-john_at_gmx.de>>
>> <mailto:snake-john_at_gmx.de <mailto:snake-john_at_gmx.de>
>>
>> <mailto:snake-john_at_gmx.de <mailto:snake-john_at_gmx.de>>>>
>>
>> wrote:
>>
>> Hello Mark,
>> if you want maybe you could post your Jmeter code to the
>> users_at_grizzly.dev.java.net
>> <mailto:users_at_grizzly.dev.java.net>
>> <mailto:users_at_grizzly.dev.java.net
>> <mailto:users_at_grizzly.dev.java.net>>
>> <mailto:users_at_grizzly.dev.java.net
>> <mailto:users_at_grizzly.dev.java.net>
>> <mailto:users_at_grizzly.dev.java.net
>> <mailto:users_at_grizzly.dev.java.net>>> ?
>>
>>
>> I could take a look there and I think some other users
>> might then
>> have sugesstions for you..
>>
>> The best solution depends on your protocol:
>>
>> for many protocols it often works to just stay on the
>> protocoChain
>> transaction
>> and call
>> com.sun.grizzly.util.OutputWriter.flushChannel when
>> you have
>> read in
>> the client message.
>> Maybe
>>
>> context.getAsyncQueueWritable().writeToAsyncQueue(byteBuffer)
>> would also make
>> sense. it really depends on your server code (-:
>>
>> Many Greetings John
>>
>>
>> -------- Original-Nachricht --------
>> > Datum: Wed, 23 Jul 2008 15:07:41 +1000
>> > Von: "Mark Macumber" <mark.macumber_at_gmail.com
>> <mailto:mark.macumber_at_gmail.com>
>> <mailto:mark.macumber_at_gmail.com
>> <mailto:mark.macumber_at_gmail.com>>
>> <mailto:mark.macumber_at_gmail.com
>> <mailto:mark.macumber_at_gmail.com>
>> <mailto:mark.macumber_at_gmail.com
>> <mailto:mark.macumber_at_gmail.com>>>>
>> > An: dev_at_grizzly.dev.java.net
>> <mailto:dev_at_grizzly.dev.java.net>
>> <mailto:dev_at_grizzly.dev.java.net
>> <mailto:dev_at_grizzly.dev.java.net>>
>> <mailto:dev_at_grizzly.dev.java.net
>> <mailto:dev_at_grizzly.dev.java.net>
>> <mailto:dev_at_grizzly.dev.java.net <mailto:dev_at_grizzly.dev.java.net
>> >>>
>>
>>
>> > Betreff: TCP Responses to Client
>>
>> > Hi All,
>> >
>> > I am trying to get a TCP server running to parse my
>> own
>> protocol,
>> which I
>> > have since found many examples on. But one thing I am
>> currently
>> stuck on
>> > is
>> > how to write a response to the client that connected.
>> >
>> > I am using JMeter to connect a TCP session and send
>> some data,
>> and I seem
>> > to
>> > never get a response to to any message that I send.
>> This is
>> largely due to
>> > the fact that I dont know where exactly to write
>> anything
>> to the
>> client.
>> > Do
>> > I do it in one of the protocolfilters? Or do I have
>> to write
>> something to
>> > a
>> > SelectableChannel?
>> >
>> > Any help is greatly appreciated.
>> >
>> > Cheers,
>> > Mark
>>
>> --
>> GMX startet ShortView.de. Hier findest Du Leute mit
>> Deinen
>> Interessen!
>> Jetzt dabei sein:
>>
>> http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> dev-unsubscribe_at_grizzly.dev.java.net
>> <mailto:dev-unsubscribe_at_grizzly.dev.java.net>
>> <mailto:dev-unsubscribe_at_grizzly.dev.java.net
>> <mailto:dev-unsubscribe_at_grizzly.dev.java.net>>
>> <mailto:dev-unsubscribe_at_grizzly.dev.java.net
>> <mailto:dev-unsubscribe_at_grizzly.dev.java.net>
>> <mailto:dev-unsubscribe_at_grizzly.dev.java.net
>> <mailto:dev-unsubscribe_at_grizzly.dev.java.net>>>
>>
>> For additional commands, e-mail:
>> dev-help_at_grizzly.dev.java.net
>> <mailto:dev-help_at_grizzly.dev.java.net>
>> <mailto:dev-help_at_grizzly.dev.java.net
>> <mailto:dev-help_at_grizzly.dev.java.net>>
>> <mailto:dev-help_at_grizzly.dev.java.net
>> <mailto:dev-help_at_grizzly.dev.java.net>
>> <mailto:dev-help_at_grizzly.dev.java.net
>> <mailto:dev-help_at_grizzly.dev.java.net>>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>> <mailto:dev-unsubscribe_at_grizzly.dev.java.net>
>> <mailto:dev-unsubscribe_at_grizzly.dev.java.net
>> <mailto:dev-unsubscribe_at_grizzly.dev.java.net>>
>> For additional commands, e-mail:
>> dev-help_at_grizzly.dev.java.net <mailto:
>> dev-help_at_grizzly.dev.java.net>
>> <mailto:dev-help_at_grizzly.dev.java.net
>> <mailto:dev-help_at_grizzly.dev.java.net>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>> <mailto:dev-unsubscribe_at_grizzly.dev.java.net>
>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>> <mailto:dev-help_at_grizzly.dev.java.net>
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
>