Web Services Resource Access Working Group Teleconference

<trackbot> Date: 08 June 2010

<Bob> scribe: Fred Maciel

<Bob> scribenick: Fred_Maciel

approval of agenda

No opposition, agenda approved.

approval of the minutes

RESOLUTION: No opposition, minutes of 2010-06-01 approved

issue 9610

Heartbeat is in fact a keepalive.

Rate is expected to be long, usually around 5 minutes, so no undue burden on the network.

<DaveS> Question: Is the current mechanism only one way, or is the subscriber also tested for being allive by the event deliverer?

<MartinC> where are my skis

<Bob> http 1.1 specifies "persistent" connections

<Bob> http 1.0 had a keep alive mechanism, but it got useless in http 1.1

<Bob> tcp keep alive is a 60 byte request

<Bob> but it is widely ignored

<dug> I would prefer a KeepAlive notification and just make sure your filter includes it

<Bob> tradeoff on persistent connections is the thread needed for each one

<dug> I can't help but wonder why we're so concerned about a Sub vanishing but not a Transfer resource?

<MartinC> but this is a fault tolerance issue

<dug> well, w/o RM the heartbeat could be lost

<MartinC> this seems to be about connection availability not about server/subscription. we dont explictly tie a subscription to a single connection

<gpilz> If the event source terminates a subscription unexpectedly, and it supports the use of the EndTo EPR, and the EndTo EPR was present in the Subscribe message for that subscription (see 4.1 Subscribe), the SubscriptionEnd message MUST be sent to the endpoint reference indicated by that EPR, if possible.

<asoldano> is the status of the communication link really a concern of ws-ra?

<dug> I didn't think so

<dug> SubEnd will tell you that

<MartinC> of course the alive is only sent if the subscription is active, but it only tests the connection

<MartinC> no alive will be sent if a subscription has expired

<asoldano> lol

<Bob> +1 dave

<MartinC> +1

<MartinC> good idea bob

Summary: there are different kinds of deployment scenarios that will need different kinds of periodic messages. Might need to be a special message type dependent on the domain of implementation.

<dug> only issue with a heartbeat event sent due to a filter is that you have no control over the timing of it

<dug> bob - didn't you mean all of this under one subscription?

<DaveS> I did.

<dug> we'd need to modify the Filter stuff to have more than one filter (and make them an OR), no?

<dug> we could define some AND and OR filters, then people could mix-n-match to get the exact events they want

<MartinC> i still think the cleanest solution here is to define a special event

<MartinC> in some other spec!

<MartinC> there are problems with all proposals ina general context

<MartinC> throttling and aliveness are orthogonal concepts

<Bob> a) heartbeat proposal by gil/wsman

<Bob> b) domain defined event type that could be subscribed / filter

<Bob> c) device/domain fixed behavior

<Bob> d) add interval & count to getstatus/verify

<Bob> e) cwna

<dug> f) cwna & kill current verify

<MartinC> me have run out of time so can we think about this for next meeting

Q: can you live with one of these approaches?

RedHat: b c e f

IBM: b e f

Fujitsu: b d e f

Hitachi: abstain

Oracle: d e f

<MartinC> i can live with b, gil couldn't

Avaya: a b d e f

SoftwareAG: b e f

<MartinC> next week please!

<dug> at least B is a more generic solution

<MartinC> agreed

Continue discussion next week on "b", "e" or "f".

<MartinC> zzzzzzzzzzzzzzz