Home » Archived » Test and Performance Tools Platform (TPTP) » Questions about IAC
| Questions about IAC [message #27794] |
Tue, 23 August 2005 12:49  |
Eclipse User |
|
|
|
Hello TPTP members,
i read about the IAC in mailing-list and bugzilla.
I think you are interested in (1) communication speedup (no passing through
osi layers and operating system) and (2) simplification of usage (user don't
need to know about AC when working local).
What will you do if an AC is needed which is running as deamon process on the same machine?
2 possible scenarios:
(a) A system administrator would like to use a tptp based management tool for it's cluster.
But he would like to use it from any of the machines, which is part of the cluster.
(b) A software development company for distributed systems: Every developer is working on a
machine, which is part of a testbed (i.e. it is a host for a part of the distributed software).
The developer might need to test its software he is working on, in the testbed, so he need to
start the workbench on it's working place.
Both scenarios depict a use case, where an always running daemon process is needed on the machine
where the workbench is launched. And as far as i know, you ca't simply ignore a running deamon,
because he might hold some connections to other ACs (i'm thinking about Service Agents).
In consideration of this circumstances, i think you should leave the AC as seperated process in
future. Instead of integration, you can close the gap between AC and workbench by using
shared memory or pipes. This will result in nearly the same speedup like integrating the AC,
because you'r already working with streams instead of complex data structures, which need to
be encoded, decoded and transfered via JNI to reach your java based plugin. To meet requirement (2)
you can simply check for a running local AC in background and start it on demand.
The other benefit will be, that you do not need to reimplement a java based AC (as you discussed)
and you won't have to maintain 2 conceptual versions of the AC (i think you already have many
hardware and os specific versions).
Hope it's not big shit and it will help you to improve the framework (in any way).
;-)
Greetings
Holger
|
|
|
| Re: Questions about IAC [message #32665 is a reply to message #27794] |
Thu, 22 September 2005 11:49  |
| Eclipse User |
|
|
|
Hello,
can i please get any statement?
Thanks in advance
Holger Machens
Holger Machens schrieb:
>Hello TPTP members,
>
>
>i read about the IAC in mailing-list and bugzilla.
>
>I think you are interested in (1) communication speedup (no passing through
>osi layers and operating system) and (2) simplification of usage (user don't
>need to know about AC when working local).
>
>
>What will you do if an AC is needed which is running as deamon process on the same machine?
>
>2 possible scenarios:
>(a) A system administrator would like to use a tptp based management tool for it's cluster.
>But he would like to use it from any of the machines, which is part of the cluster.
>(b) A software development company for distributed systems: Every developer is working on a
>machine, which is part of a testbed (i.e. it is a host for a part of the distributed software).
>The developer might need to test its software he is working on, in the testbed, so he need to
>start the workbench on it's working place.
>
>Both scenarios depict a use case, where an always running daemon process is needed on the machine
>where the workbench is launched. And as far as i know, you ca't simply ignore a running deamon,
>because he might hold some connections to other ACs (i'm thinking about Service Agents).
>
>
>In consideration of this circumstances, i think you should leave the AC as seperated process in
>future. Instead of integration, you can close the gap between AC and workbench by using
>shared memory or pipes. This will result in nearly the same speedup like integrating the AC,
>because you'r already working with streams instead of complex data structures, which need to
>be encoded, decoded and transfered via JNI to reach your java based plugin. To meet requirement (2)
>you can simply check for a running local AC in background and start it on demand.
>
>The other benefit will be, that you do not need to reimplement a java based AC (as you discussed)
>and you won't have to maintain 2 conceptual versions of the AC (i think you already have many
>hardware and os specific versions).
>
>
>Hope it's not big shit and it will help you to improve the framework (in any way).
>;-)
>
>
>Greetings
> Holger
>
>
|
|
|
| Re: Questions about IAC [message #32730 is a reply to message #32665] |
Fri, 23 September 2005 09:57 |
| Eclipse User |
|
|
|
Originally posted by: Navid_Mehregani_nmehrega.ca.ibm.com
This is a multipart message in MIME format.
--=_alternative 004CA59F85257085_=
Content-Type: text/plain; charset="US-ASCII"
Hi Holger,
I apologize for the late response. I was hoping that the main IAC
developer would address your concerns.
>I think you are interested in (1) communication speedup (no passing
through
>osi layers and operating system) and (2) simplification of usage (user
don't
>need to know about AC when working local).
You're exactly right, this was the motivation behind IAC. #2, however,
was the main reason why the IAC project was initiated.
>What will you do if an AC is needed which is running as deamon process on
the same machine?
IAC will NOT replace AC. The Agent Controller will still be there and the
user will still have the option of using AC locally. The user is able to
have both IAC and AC on the same machine, but only one of them can be
running at any given time. You can't run IAC and AC concurrently because
they both use the same named pipe. If IAC is running, AC won't be able
to start and vice versa. Essentially, IAC will start when the user
launches the workbench (provided that AC is not running). IAC will
release the named pipe when the last agent detaches itself from it.
If the AC is running when the user launches the workbench, IAC will
graciously fail to start.
The UI is scheduled to be changed for 4.1 I2 to allow the user to select
either IAC or AC when profiling/logging/testing locally. By default IAC
will be selected when the user wants to work locally, but the user has the
option of changing that.
I hope that clarifies things,
Navid Mehregani
IBM Canada
--=_alternative 004CA59F85257085_=
Content-Type: text/html; charset="US-ASCII"
<br><font size=2 face="sans-serif">Hi Holger,</font>
<br>
<br><font size=2 face="sans-serif">I apologize for the late response. I
was hoping that the main IAC developer would address your concerns.</font>
<br>
<br><font size=2><tt>>I think you are interested in (1) communication
speedup (no passing through<br>
>osi layers and operating system) and (2) simplification of usage (user
don't<br>
>need to know about AC when working local).</tt></font>
<br>
<br><font size=2 face="sans-serif">You're exactly right, this was the motivation
behind IAC. #2, however, was the main reason why the IAC project
was initiated.</font>
<br>
<br><font size=2><tt>>What will you do if an AC is needed which is running
as deamon process on the same machine?</tt></font>
<br>
<br><font size=2 face="sans-serif">IAC will NOT replace AC. The Agent
Controller will still be there and the user will still have the option
of using AC locally. The user is able to have both IAC and AC on
the same machine, but only one of them can be running at any given time.
You can't run IAC and AC concurrently because they both use the same
named pipe. If IAC is running, AC won't be able to start and vice
versa. Essentially, IAC will start when the user launches the workbench
(provided that AC is not running). IAC will release the named pipe
when the last agent detaches itself from it. </font>
<br><font size=2 face="sans-serif">If the AC is running when the user launches
the workbench, IAC will graciously fail to start.</font>
<br>
<br><font size=2 face="sans-serif">The UI is scheduled to be changed for
4.1 I2 to allow the user to select either IAC or AC when profiling/logging/testing
locally. By default IAC will be selected when the user wants to work
locally, but the user has the option of changing that.</font>
<br>
<br><font size=2 face="sans-serif">I hope that clarifies things,</font>
<br>
<br><font size=2 face="sans-serif">Navid Mehregani<br>
IBM Canada</font>
--=_alternative 004CA59F85257085_=--
|
|
|
| Re: Questions about IAC [message #32843 is a reply to message #32730] |
Tue, 27 September 2005 06:46 |
| Eclipse User |
|
|
|
Hi Navid,
thanks a lot for your details.
This is a very simple and effective way to keep in mind the
circumstances i mentioned.
Greetings
Holger Machens
Navid_Mehregani_nmehrega@ca.ibm.com schrieb:
>
> Hi Holger,
>
> I apologize for the late response. I was hoping that the main IAC
> developer would address your concerns.
>
> >I think you are interested in (1) communication speedup (no passing
> through
> >osi layers and operating system) and (2) simplification of usage
> (user don't
> >need to know about AC when working local).
>
> You're exactly right, this was the motivation behind IAC. #2,
> however, was the main reason why the IAC project was initiated.
>
> >What will you do if an AC is needed which is running as deamon
> process on the same machine?
>
> IAC will NOT replace AC. The Agent Controller will still be there and
> the user will still have the option of using AC locally. The user is
> able to have both IAC and AC on the same machine, but only one of them
> can be running at any given time. You can't run IAC and AC
> concurrently because they both use the same named pipe. If IAC is
> running, AC won't be able to start and vice versa. Essentially, IAC
> will start when the user launches the workbench (provided that AC is
> not running). IAC will release the named pipe when the last agent
> detaches itself from it.
> If the AC is running when the user launches the workbench, IAC will
> graciously fail to start.
>
> The UI is scheduled to be changed for 4.1 I2 to allow the user to
> select either IAC or AC when profiling/logging/testing locally. By
> default IAC will be selected when the user wants to work locally, but
> the user has the option of changing that.
>
> I hope that clarifies things,
>
> Navid Mehregani
> IBM Canada
|
|
|
Goto Forum:
Current Time: Wed Aug 13 15:07:03 EDT 2025
Powered by FUDForum. Page generated in 0.02990 seconds |
Home