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>
>
>