<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Comments below. Give this discussion lower priority than
release-related tasks...<br>
<br>
Ivan R. Judson wrote:<br>
<blockquote type="cite" cite="mid200403220322.i2M3MK0140380@mcs.anl.gov">
<pre wrap="">I have a lot of questions, but I'm definitely not opposed to the idea.
Questions:
1) Are you suggesting this for this cycle? We nominally froze code last
Friday (or were trying to) we really need to close this cycle asap to do any
real testing.
</pre>
</blockquote>
I was throwing it out for discussion only. I don't see that it could
go in this release, due to the timeline and its impact on client/server
compatibility.<br>
<blockquote type="cite" cite="mid200403220322.i2M3MK0140380@mcs.anl.gov">
<pre wrap="">
2) Is it true that heartbeats are the only event channel data (currently)
that are sent from client to server? By moving this to SOAP are you
implying that services will do the same (I'm thinking a data storage service
that gets files dumped into it needs to indicate such a change to the
venue(s) it's present in). This looks like a general design suggestion that
the venue is the *only* source of event data, all data that results in event
generation is done via SOAP...
</pre>
</blockquote>
Clients _do_ send data other than heartbeats, but those are not for
membership. <br>
<blockquote type="cite" cite="mid200403220322.i2M3MK0140380@mcs.anl.gov">
<pre wrap="">
3) I would argue we *have* to do either the OpenSSL or unsecured SOAP to
make this feasible, a call every n seconds that takes ~1 second overhead is
the wrong performance ratio to be living with, when n < 100, IMHO.
</pre>
</blockquote>
This point and the one below speak to performance, which we would
certainly need to consider. In fact, we have felt that pressure ever
since we plugged in GSI beneath SOAP, so we need to look into it anyway.<br>
<blockquote type="cite" cite="mid200403220322.i2M3MK0140380@mcs.anl.gov">
<pre wrap="">
4) Do we know we can mix SOAP server/clients, GSI server, SSL client? If so
can we mix unsecured and use session headers to make it even faster?
5) What effect if any does this have on the potential design changes for the
event/text channels (merging them into a more basic communication channel
with a richer data protocol), since text is mostly client produced data, if
any server produced (this seems to be a direct counter example for moving
heartbeats if it's working, doesn't it?)
</pre>
</blockquote>
I don't see that it has any impact on changes of that type for the
event/text channels. Could you explain why it's a counter-example?<br>
<br>
<blockquote type="cite" cite="mid200403220322.i2M3MK0140380@mcs.anl.gov">
<pre wrap="">
--Ivan
</pre>
<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:owner-ag-dev@mcs.anl.gov">owner-ag-dev@mcs.anl.gov</a>
[<a class="moz-txt-link-freetext" href="mailto:owner-ag-dev@mcs.anl.gov">mailto:owner-ag-dev@mcs.anl.gov</a>] On Behalf Of Robert Olson
Sent: Saturday, March 20, 2004 12:45 PM
To: Thomas D. Uram
Cc: <a class="moz-txt-link-abbreviated" href="mailto:ag-dev@mcs.anl.gov">ag-dev@mcs.anl.gov</a>
Subject: Re: Venue membership via soap?
I think it's a great idea. If there's concern over the GSI
connection overhead, we can do straight SSL with connection tokens.
--bob
On Sat, 20 Mar 2004, Thomas D. Uram wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Considering the difficulties we've had with the event
</pre>
</blockquote>
<pre wrap="">service, and the
</pre>
<blockquote type="cite">
<pre wrap="">concerns people have about losing their membership in a venue (and
having their media tools shutdown), I was wondering if we
</pre>
</blockquote>
<pre wrap="">should move
</pre>
<blockquote type="cite">
<pre wrap="">membership management (i.e. heartbeats) over to the SOAP realm.
Especially considering that the SOAP server is now
</pre>
</blockquote>
<pre wrap="">multithreaded, this
</pre>
<blockquote type="cite">
<pre wrap="">could be more reliable than the event channel, and would leave the
event channel strictly to managing coherence.
This would simplify some services, too. If they're not
</pre>
</blockquote>
<pre wrap="">concerned with
</pre>
<blockquote type="cite">
<pre wrap="">coherence, they don't need an event client.
Thoughts?
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>