I see the problem of understanding it...
Sending A, receiving A-ack and sending B are not realy sequential, it is
like that just!!! in the first time, because, the server sends 'A-ack'
just after it'll have 'A' messages in its queue so there is coupling
between the server's 'A' messegase queue and the client's 'A-ack' queue,
not between the client's 'A' messages and the client's 'A-ack' messages,
they indifferent.
Also between 'A-ack' and 'B'. 'A-ack' can be received from the server
indifferently to the fact that the client sends 'B' and the sending 'B'
is not dependent if 'A-ack' was just sent, it can deal with an 'A-ack'
that was sent a hour ago.
Lets take another example:
Thread1(loop)
|- a waiter puts food on the buffet table
|- Eitan takes food to eat
|- Eitan takes a toothpick
for the first time the process are sequential. Eitan will not be able to
take food unless the waiter puts it there (he waits for the food).
Eitan will not pick his teeth unless he ate something (took food from
the table). but the processes are indifferent to each other: the waiter
can continue to put food on the table even if Eitan didn't take some
food from the table, of even if Eitan didn't pick his teath, Eitan can
pick his teeth from flakes (I am sorry for this story) of food he took
from the table two servings ago...
so it should be:
Thread1(loop)
|- a waiter puts food on the buffet table
Thread2(loop)
|- Eitan takes food to eat
Thread3(loop)
|- Eitan takes a toothpick
at first thread2 won't start till thread1 has started, and theard3 won't
start till thread2 has started, but after that they are independent.
You wrote:
> but a single thread is simulating a single client, and this is how clients work, no?
>
I don't think so, client can open several threads, the meaning of
"clienting" is to connect to one server (a server can connect to several
clients) and to connect to server that is already up (the server goes up
first).
> But add a second thread (second client), and now you have two 'message A' being sent
> simultaneously. Add 500 threads, and you'll have 500 parallel message A's.
There is a big problem here, that called window size of 500, I won't
elaborate (I know that you are a very busy man that need to develop,
document and answering mails from annoying people like me...) but try to
imagine that the waiter is waiting after each meal he put, for the
customers to finish picking their teeth (sorry again), you as a manager
probably won't hire 500 waiter to each wait for the picking, but you'll
tell the waiter to keep put meals relentlessly (he would act like a
seperate thread).
On Wed, 22 Sep 2004 08:21:13 -0400, "Michael Stover"
<[EMAIL PROTECTED]> said:
> I must be seriously misunderstanding something because, to me, it sounds
> like you are describing a bunch of independent threads doing three
> sequential steps, which is exactly how JMeter works. See my comments
> below:
>
> On Wed, 2004-09-22 at 05:35, [EMAIL PROTECTED] wrote:
> > I know that this mailing list is not meant for design, but if we already
> > started...
> >
> > I'm sorry, but I've to disagree. We're talking about client/server
> > architecture, I'm a client and I want to send maximum load to the
> > server.
> > In one thread architecture it will look like that:
> >
> > Thread(loop)
> > |- Send TCP/IP message (to server)
> > |
> > |- Wait for TCP/IP Ack message (from server)
>
> Two sequential steps.
>
> >
> > In an implementation like that, there will be a situation called 'window
> > size = one', that means that the client can't send another message till
> > it gets an ack message from the server (it can send just one message
> > till the ack), and that reduces the load significantly (that's a fact),
> > I don't want to wait for the Acks, I want to keep sending.
>
> You say you don't want to wait, but you contradict that below. In fact,
> it seems you have to wait.
>
> > by decoupling those processes I can also elaborate things, like I
> > described in the previous mail:
> >
> > Thread1(loop)
> > |- Send message A
> >
> > Thread2(loop)
> > |- Wait for Ack (save a special field - f1, push in shared Q)
> >
> > Thread3(loop)
> > |- Send message B sometimes in the future (according to field f1 - pop
> > from shared Q)
>
> Now you are describing three sequential steps, each dependent on the
> previous step. For some reason, you want to use three threads and make
> them wait on one another (complicated) when a single thread will simply
> work that way.
>
> >
> > As you can see, I can't do it in one thread (I won't be able to send a
> > second message A till the B message will be send
>
> With a single thread, that's true, but a single thread is simulating a
> single client, and this is how clients work, no? But add a second
> thread (second client), and now you have two 'message A' being sent
> simultaneously. Add 500 threads, and you'll have 500 parallel message
> A's.
>
> > - sometime in the
> > future). I want to send as much messages A in a second, as I can.
>
> I would like to see how you would do it with 3 threads, and keep each
> set of message A - Ack - message B together. Certainly you can't do it
> in JMeter even with some global variable storage.
>
> -Mike
>
> >
> > And now for the real problem, you wrote: "Variables are not shared
> > across threads. JMeter simulates multiple independent users", That's
> > okay, I want to simulate it myself. like the "User Defined Variables" in
> > the Test Plan.
> >
> > Can you write something on how it is done (ValueReplacer...)
> >
> > Thanks a million
> >
> > P.S
> > I can always use global queue, but... you know
> >
> >
> >
> > On Tue, 21 Sep 2004 11:16:29 -0400, "Michael Stover"
> > <[EMAIL PROTECTED]> said:
> > > That seems like exactly the sort of thing you'd do in one thread. An
> > > initial request gets some data and a subsequent request uses it. How
> > > else would you manage 100 threads doing this?
> > >
> > > -Mike
> > >
> > > On Tue, 2004-09-21 at 10:53, [EMAIL PROTECTED] wrote:
> > > > Okay, so how can I do it?
> > > > What I'm planing, is to use in one thread, a derived
> > > > 'AbstractJavaSamplerClient' to get TCP/IP packet (a request) and to pars
> > > > it. according to this request, another thread will send another request
> > > > (let's say the ack part) - using other derived
> > > > 'AbstractJavaSamplerClient' that will be under an 'IfController' (in the
> > > > 'IfController' the user will "ask" if a specific value equals to
> > > > something).
> > > > I don't think it's wise to do both process in the same thread.
> > > >
> > > > Thanks again, especially for your quick answer.
> > > >
> > > > On Tue, 21 Sep 2004 09:50:01 -0400, "Michael Stover"
> > > > <[EMAIL PROTECTED]> said:
> > > > > Variables are not shared across threads. JMeter simulates multiple
> > > > > independent users, so there hasn't been any need to shared data amongst
> > > > > the threads during the test run.
> > > > >
> > > > > -Mike
> > > > >
> > > > > On Tue, 2004-09-21 at 09:27, [EMAIL PROTECTED] wrote:
> > > > > > I want to save variables that were initialized in one thread, so they
> > > > > > will be seen in other thread.
> > > > > > There is an easy way to save variables in the thread's context:
> > > > > > JMeterContext context = getThreadContext();
> > > > > > JMeterVariables vars = context.getVariables();
> > > > > > vars.put(....
> > > > > >
> > > > > > But trying to save variables so they will be seen in all the threads is
> > > > > > much harder, I looked at: PreCompiler.addNode(Object,HashTree)
> > > > > > and in my code tried naively to write:
> > > > > > JMeterContextService.getContext().getVariables().put("code", "value");
> > > > > > but this key was unvisible in other threads. I've noticed that there is
> > > > > > some action doing with an instance of 'ValueReplacer' in the 'addNode'
> > > > > > func, but still didn't figure to find out what to do.
> > > > > > Tips will be most welcom
> > > > > >
> > > > > > Thanks.
> > > > > --
> > > > > Michael Stover <[EMAIL PROTECTED]>
> > > > > Apache Software Foundation
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > >
> > > --
> > > Michael Stover <[EMAIL PROTECTED]>
> > > Apache Software Foundation
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> --
> Michael Stover <[EMAIL PROTECTED]>
> Apache Software Foundation
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
--
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
