Salut,
forgot to add the link:
http://weblogs.java.net/blog/sdo/archive/2007/04/simple_benchmar.html
-- Jeanfrancois
Jeanfrancois Arcand wrote:
> Salut,
>
> Mark Macumber wrote:
>> 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?
>
> Can you elaborate on what you want exactly? One thing I can recommend is
> to look at the following blog, which describe a tool called Faban that
> can be used to stress TCP/HTTP client.
>
> Thanks!
>
> -- Jeanfrancois
>
> 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 <mailto: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>
>> <mailto: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>>
>> <mailto: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>>>
>> <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
>> <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>>>
>> <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
>> <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>>>
>> <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
>> <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>>>
>> <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
>> <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>>>
>> <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
>> <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>>>
>> <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
>> <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>>
>> <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
>