Hi,
Thanks for the tip, is this the same as doing:
SelectableChannel selectableChannel = ctx.getSelectionKey().channel();
selectableChannel.close();
??
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.
Cheers,
Mark
On Thu, Jul 24, 2008 at 11:02 AM, Jeanfrancois Arcand <
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>> 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>>> 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>> ?
>>
>>
>> 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>>>
>> > 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
>> >>
>>
>>
>> > 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>>
>>
>> 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
>
>