TCP Responses to Client

View: New views
11 Messages — Rating Filter:   Alert me  

TCP Responses to Client

by Kram :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

Re: TCP Responses to Client

by John ROM :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hello Mark,
if you want maybe you could post your Jmeter code to the users@... ?

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@...>
> An: dev@...
> 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@...
For additional commands, e-mail: dev-help@...


Re: TCP Responses to Client

by Kram :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

Cheers,
Mark

On Wed, Jul 23, 2008 at 5:02 PM, John ROM <snake-john@...> wrote:
Hello Mark,
if you want maybe you could post your Jmeter code to the users@... ?

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@...>
> An: dev@...
> 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@...
For additional commands, e-mail: dev-help@...



Re: TCP Responses to Client

by Jeanfrancois Arcand-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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@...
> <mailto:snake-john@...>> wrote:
>
>     Hello Mark,
>     if you want maybe you could post your Jmeter code to the
>     users@... <mailto:users@...> ?
>
>     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@...
>     <mailto:mark.macumber@...>>
>      > An: dev@... <mailto:dev@...>
>      > 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@...
>     <mailto:dev-unsubscribe@...>
>     For additional commands, e-mail: dev-help@...
>     <mailto:dev-help@...>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...


Re: TCP Responses to Client

by Kram :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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@...> 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@... <mailto:snake-john@...>> wrote:

   Hello Mark,
   if you want maybe you could post your Jmeter code to the
   users@... <mailto:users@...> ?


   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@...
   <mailto:mark.macumber@...>>
    > An: dev@... <mailto:dev@...>

    > 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@...
   <mailto:dev-unsubscribe@...>

   For additional commands, e-mail: dev-help@...
   <mailto:dev-help@...>



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...



Re: TCP Responses to Client

by Jeanfrancois Arcand-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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@... <mailto:Jeanfrancois.Arcand@...>> 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@...
>         <mailto:snake-john@...> <mailto:snake-john@...
>         <mailto:snake-john@...>>> wrote:
>
>            Hello Mark,
>            if you want maybe you could post your Jmeter code to the
>            users@...
>         <mailto:users@...>
>         <mailto:users@...
>         <mailto:users@...>> ?
>
>
>            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@...
>         <mailto:mark.macumber@...>
>            <mailto:mark.macumber@...
>         <mailto:mark.macumber@...>>>
>             > An: dev@...
>         <mailto:dev@...>
>         <mailto:dev@... <mailto:dev@...>>
>
>             > 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@...
>         <mailto:dev-unsubscribe@...>
>            <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>
>
>            For additional commands, e-mail:
>         dev-help@... <mailto:dev-help@...>
>            <mailto:dev-help@...
>         <mailto:dev-help@...>>
>
>
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: dev-unsubscribe@...
>     <mailto:dev-unsubscribe@...>
>     For additional commands, e-mail: dev-help@...
>     <mailto:dev-help@...>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...


Re: TCP Responses to Client

by Kram :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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@...> 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@... <mailto:Jeanfrancois.Arcand@...>> 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@...
       <mailto:snake-john@...> <mailto:snake-john@...

       <mailto:snake-john@...>>> wrote:

          Hello Mark,
          if you want maybe you could post your Jmeter code to the
          users@...
       <mailto:users@...>
       <mailto:users@...
       <mailto:users@...>> ?


          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@...
       <mailto:mark.macumber@...>
          <mailto:mark.macumber@...
       <mailto:mark.macumber@...>>>
           > An: dev@...
       <mailto:dev@...>
       <mailto:dev@... <mailto:dev@...>>


           > 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@...
       <mailto:dev-unsubscribe@...>
          <mailto:dev-unsubscribe@...
       <mailto:dev-unsubscribe@...>>

          For additional commands, e-mail:
       dev-help@... <mailto:dev-help@...>
          <mailto:dev-help@...
       <mailto:dev-help@...>>



   ---------------------------------------------------------------------
   To unsubscribe, e-mail: dev-unsubscribe@...
   <mailto:dev-unsubscribe@...>
   For additional commands, e-mail: dev-help@...
   <mailto:dev-help@...>



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...



Re: TCP Responses to Client

by Jeanfrancois Arcand-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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@... <mailto:Jeanfrancois.Arcand@...>> 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@...
>         <mailto:Jeanfrancois.Arcand@...>
>         <mailto:Jeanfrancois.Arcand@...
>         <mailto:Jeanfrancois.Arcand@...>>> 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@... <mailto:snake-john@...>
>                <mailto:snake-john@... <mailto:snake-john@...>>
>         <mailto:snake-john@... <mailto:snake-john@...>
>
>                <mailto:snake-john@... <mailto:snake-john@...>>>>
>         wrote:
>
>                   Hello Mark,
>                   if you want maybe you could post your Jmeter code to the
>                   users@...
>         <mailto:users@...>
>                <mailto:users@...
>         <mailto:users@...>>
>                <mailto:users@...
>         <mailto:users@...>
>                <mailto:users@...
>         <mailto:users@...>>> ?
>
>
>                   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@...
>         <mailto:mark.macumber@...>
>                <mailto:mark.macumber@...
>         <mailto:mark.macumber@...>>
>                   <mailto:mark.macumber@...
>         <mailto:mark.macumber@...>
>                <mailto:mark.macumber@...
>         <mailto:mark.macumber@...>>>>
>                    > An: dev@...
>         <mailto:dev@...>
>                <mailto:dev@...
>         <mailto:dev@...>>
>                <mailto:dev@...
>         <mailto:dev@...>
>         <mailto:dev@... <mailto:dev@...>>>
>
>
>                    > 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@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>
>                   <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>                <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>>
>
>                   For additional commands, e-mail:
>                dev-help@...
>         <mailto:dev-help@...>
>         <mailto:dev-help@...
>         <mailto:dev-help@...>>
>                   <mailto:dev-help@...
>         <mailto:dev-help@...>
>                <mailto:dev-help@...
>         <mailto:dev-help@...>>>
>
>
>
>          
>          ---------------------------------------------------------------------
>            To unsubscribe, e-mail: dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>
>            <mailto:dev-unsubscribe@...
>         <mailto:dev-unsubscribe@...>>
>            For additional commands, e-mail:
>         dev-help@... <mailto:dev-help@...>
>            <mailto:dev-help@...
>         <mailto:dev-help@...>>
>
>
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: dev-unsubscribe@...
>     <mailto:dev-unsubscribe@...>
>     For additional commands, e-mail: dev-help@...
>     <mailto:dev-help@...>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...


Re: TCP Responses to Client

by Kram :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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@...> 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@... <mailto:Jeanfrancois.Arcand@...>> wrote:

   Salut,


   Mark Macumber w