Hello Jeanfrancois,
Yes that is correct I believe we were using HTTP 1.0, so that explains
everything. :)
Cheers,
Mark
On Thu, Jul 24, 2008 at 10:49 AM, Jeanfrancois Arcand <
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>> 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> ?
>>
>> 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>>
>> > An: 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>
>> 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
>
>