Discussion of the OpenPegasus implementation of the WBEM distributed management standard

Wen Chen | 1 Jun 2007 04:17

indication subscrition persistence across cimserver restart

Hi,

I am using Pegasus 2.6.

I have noticed these subscription persistence behaviors during cimserver restart:

1. indication filters, handlers, and subscriptions survive cimserver restart.

2. cimserver does not call the enable/create/modifySubscription methods on providers after a restart, so that providers will not know if there are pre-existing subscriptions in the system.

The above behaviors contradict each other’s design intentions. What’s your approach for your providers to recognize pre-existing subscriptions?

Thanks,

Wen

headers

Kirk Augustin | 1 Jun 2007 05:55

Re: indication subscrition persistence across cimserver restart

Providers are responsible for their own data persistence.
Since the providers generate the indication events, and should store their own list of subscribers, it would be wrong for Pegasus to keep recreating subscriptions.
The server should stay out of it.

Personally I think indications are designed wrong, should time out often, and need constant resubscribing, thus avoiding orphaned subscriptions.
But that would add more traffic to the providers.

----- Original Message ----
From: Wen Chen <hi.wen.chen <at> gmail.com>
To: pegasus-l <at> opengroup.org
Sent: Thursday, May 31, 2007 7:17:51 PM
Subject: indication subscrition persistence across cimserver restart

Hi,

I am using Pegasus 2.6.

I have noticed these subscription persistence behaviors during cimserver restart:

1. indication filters, handlers, and subscriptions survive cimserver restart.

2. cimserver does not call the enable/create/modifySubscription methods on providers after a restart, so that providers will not know if there are pre-existing subscriptions in the system.

The above behaviors contradict each other’s design intentions. What’s your approach for your providers to recognize pre-existing subscriptions?

Thanks,

Wen

headers

Padmanabhachar, Dhananjaya | 1 Jun 2007 08:32

Problem in http and https Ports with Pegasus and WMIMapper

Hi,

I have some issue with http port and https ports in Pegasus and WMIMapper. I configured Pegasus and WMIMapper on the following ports:-

Provider httpPort httpsPort

Pegasus 5988 5989

WMIMapper 5002 5003

I am writing java CIM client to enumerate the classes. I use the following,

https://192.59.152.61:5003 (WMIMapper)

https://192.59.152.61:5989 (Pegasus)

This works fine as the port numbers are correctly used.

Now the big problem is when I interchange the port numbers, say for example, I use http port in https connection like below:-

https://192.59.152.61:5002 (WMIMapper)

https://192.59.152.61:5988 (Pegasus)

The provider hangs and does not throw any exception!!

It looks to me that, Pegasus and WMIMapper have not handled this exception!! Please let me know if this is a bug in Pegasus and WMIMapper??

Thanks and Best Regards

Dhananjaya

Unisys Global Services - India | 'Purva Premier', 135/1, Residency Road, Bangalore -560 025 | Tel:+91 (80)4159 4000 Dir:+91 (80)4159 4663

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.

headers

Michael E. Brasher | 1 Jun 2007 15:57

RE: indication subscrition persistence across cimserver restart

Hello Wen,

I just tested both the CMPI and OpenPegasus C++ provider interfaces and for me they both

call enable-indications for me. To do this my client initially creates instances of the folowing:

CIM_IndicationSubscription

CIM_IndicationFilter

CIM_IndicationHandlerCIMXML

Her are the exact instances of those I created (I used CLI to fetch them from the server).

Perhaps it has something to do with the RepeatNotificationPolicy property but I'm not

sure. You might retry with these same properties.

Regards,

Mike

instance of CIM_IndicationSubscription

{

OtherOnFatalErrorPolicy = NULL;

FailureTriggerTimeInterval = NULL;

OtherSubscriptionState = NULL;

SubscriptionDuration = NULL;

SubscriptionTimeRemaining = NULL;

OtherRepeatNotificationPolicy = NULL;

RepeatNotificationInterval = NULL;

RepeatNotificationGap = NULL;

RepeatNotificationCount = NULL;

Filter = "CIM_IndicationFilter.CreationClassName=\"CIM_IndicationFilter\",Name=\"56C0D70B233E46668EC64BD2671D07A2\",SystemCreationClassName=\"CIM_ComputerSystem\",SystemName=\"localhost.localdomain\"";

Handler = "CIM_IndicationHandlerCIMXML.CreationClassName=\"CIM_IndicationHandlerCIMXML\",Name=\"56C0D70B233E46668EC64BD2671D07A2\",SystemCreationClassName=\"CIM_ComputerSystem\",SystemName=\"localhost.localdomain\"";

OnFatalErrorPolicy = 4;

SubscriptionState = 2;

RepeatNotificationPolicy = 2;

TimeOfLastStateChange = "20070601084000.230420-300";

SubscriptionStartTime = "20070601084000.230420-300";

};

instance of CIM_IndicationFilter

{

Caption = NULL;

Description = NULL;

ElementName = NULL;

Name = "56C0D70B233E46668EC64BD2671D07A2";

Query = "select * from CIM_Indication";

QueryLanguage = "WQL";

SourceNamespace = "root/cimv2";

CreationClassName = "CIM_IndicationFilter";

SystemName = "localhost.localdomain";

SystemCreationClassName = "CIM_ComputerSystem";

};

instance of CIM_IndicationHandlerCIMXML

{

Caption = NULL;

Description = NULL;

ElementName = NULL;

OtherPersistenceType = NULL;

Owner = NULL;

Name = "56C0D70B233E46668EC64BD2671D07A2";

Destination = "http://localhost:9999";

CreationClassName = "CIM_IndicationHandlerCIMXML";

SystemName = "localhost.localdomain";

SystemCreationClassName = "CIM_ComputerSystem";

PersistenceType = 2;

};

Mike

-----Original Message-----
From: Wen Chen [mailto:hi.wen.chen <at> gmail.com]
Sent: Thursday, May 31, 2007 9:18 PM
To: pegasus-l <at> opengroup.org
Subject: indication subscrition persistence across cimserver restart

Hi,

I am using Pegasus 2.6.

I have noticed these subscription persistence behaviors during cimserver restart:

1. indication filters, handlers, and subscriptions survive cimserver restart.

2. cimserver does not call the enable/create/modifySubscription methods on providers after a restart, so that providers will not know if there are pre-existing subscriptions in the system.

The above behaviors contradict each other’s design intentions. What’s your approach for your providers to recognize pre-existing subscriptions?

Thanks,

Wen

headers

Karl Schopmeyer | 1 Jun 2007 17:38

Re: indication subscrition persistence across cimserver restart

Thanks for your message at 10:55 PM 5/31/2007. Your message was:

Providers are responsible for their own data persistence.
Since the providers generate the indication events, and should store their own list of subscribers, it would be wrong for Pegasus to keep recreating subscriptions.
The server should stay out of it.

Incorrect. The server takes responsibilty for persistent subscriptions and restarts providers on system restart.

Personally I think indications are designed wrong, should time out often, and need constant resubscribing, thus avoiding orphaned subscriptions.
But that would add more traffic to the providers.

----- Original Message ----
From: Wen Chen <hi.wen.chen <at> gmail.com>
To: pegasus-l <at> opengroup.org
Sent: Thursday, May 31, 2007 7:17:51 PM
Subject: indication subscrition persistence across cimserver restart

Hi,

I am using Pegasus 2.6.

I have noticed these subscription persistence behaviors during cimserver restart:

1. indication filters, handlers, and subscriptions survive cimserver restart.

2. cimserver does not call the enable/create/modifySubscription methods on providers after a restart, so that providers will not know if there are pre-existing subscriptions in the system.

The above behaviors contradict each other¢s design intentions. What¢s your approach for your providers to recognize pre-existing subscriptions?

Thanks,

Wen

Karl Schopmeyer                   Inova Europe Inc.
305 Spring Creek Village, Suite 475 - Dallas TX, 75248 USA
EMAIL: k.schopmeyer <at> swbell.net       FAX: 1-972-239-0326
Phone: 1-972-788-2172,          Cell Phone 1-972-814-5581
Skype: kschopmeyer         Skype Phone: (214) 556-5971

headers

Kirk Augustin | 1 Jun 2007 21:06

Re: indication subscrition persistence across cimserver restart

No, what Wen Chen posted proves that servers are NOT responsible for renotifying providers of past subscriptions after a restart.
Sure the server restarts the providers, but is not responsible for again telling providers who has subscribed.
That is the responsibility of the providers to retain themselves.
Otherwise Wen Chen would not have noticed the behavior he is commenting on.

----- Original Message ----
From: Karl Schopmeyer <k.schopmeyer <at> swbell.net>
To: Kirk Augustin <kirk_augustin <at> yahoo.com>; Wen Chen <hi.wen.chen <at> gmail.com>; pegasus-l <at> opengroup.org
Sent: Friday, June 1, 2007 8:38:27 AM
Subject: Re: indication subscrition persistence across cimserver restart

Thanks for your message at 10:55 PM 5/31/2007. Your message was:

Providers are responsible for their own data persistence.
Since the providers generate the indication events, and should store their own list of subscribers, it would be wrong for Pegasus to keep recreating subscriptions.
The server should stay out of it.

Incorrect. The server takes responsibilty for persistent subscriptions and restarts providers on system restart.

Personally I think indications are designed wrong, should time out often, and need constant resubscribing, thus avoiding orphaned subscriptions.
But that would add more traffic to the providers.

----- Original Message ----
From: Wen Chen <hi.wen.chen <at> gmail.com>
To: pegasus-l <at> opengroup.org
Sent: Thursday, May 31, 2007 7:17:51 PM
Subject: indication subscrition persistence across cimserver restart

Hi,

I am using Pegasus 2.6.

I have noticed these subscription persistence behaviors during cimserver restart:

1. indication filters, handlers, and subscriptions survive cimserver restart.

2. cimserver does not call the enable/create/modifySubscription methods on providers after a restart, so that providers will not know if there are pre-existing subscriptions in the system.

The above behaviors contradict each other¢s design intentions. What¢s your approach for your providers to recognize pre-existing subscriptions?

Thanks,

Wen

Karl Schopmeyer                   Inova Europe Inc.
305 Spring Creek Village, Suite 475 - Dallas TX, 75248 USA
EMAIL: k.schopmeyer <at> swbell.net       FAX: 1-972-239-0326
Phone: 1-972-788-2172,          Cell Phone 1-972-814-5581
Skype: kschopmeyer         Skype Phone: (214) 556-5971

headers

Wen Chen | 1 Jun 2007 21:58

RE: indication subscrition persistence across cimserver restart

Thanks for the responses and Thanks for Kirk to speak on my behalf.

In my Pegasus 2.6, cimserver does not remind providers of pre-existing subscriptions after it restarts.

Michael Brasher described a potentially different experience in his post. I will investigate and update.

Wen

From: Kirk Augustin [mailto:kirk_augustin <at> yahoo.com]
Sent: Friday, June 01, 2007 12:07 PM
To: Karl Schopmeyer; Wen Chen; pegasus-l <at> opengroup.org
Subject: Re: indication subscrition persistence across cimserver restart

No, what Wen Chen posted proves that servers are NOT responsible for renotifying providers of past subscriptions after a restart.
Sure the server restarts the providers, but is not responsible for again telling providers who has subscribed.
That is the responsibility of the providers to retain themselves.
Otherwise Wen Chen would not have noticed the behavior he is commenting on.

----- Original Message ----
From: Karl Schopmeyer <k.schopmeyer <at> swbell.net>
To: Kirk Augustin <kirk_augustin <at> yahoo.com>; Wen Chen <hi.wen.chen <at> gmail.com>; pegasus-l <at> opengroup.org
Sent: Friday, June 1, 2007 8:38:27 AM
Subject: Re: indication subscrition persistence across cimserver restart

Thanks for your message at 10:55 PM 5/31/2007. Your message was:

Providers are responsible for their own data persistence.
Since the providers generate the indication events, and should store their own list of subscribers, it would be wrong for Pegasus to keep recreating subscriptions.
The server should stay out of it.

Incorrect. The server takes responsibilty for persistent subscriptions and restarts providers on system restart.

Personally I think indications are designed wrong, should time out often, and need constant resubscribing, thus avoiding orphaned subscriptions.
But that would add more traffic to the providers.

----- Original Message ----
From: Wen Chen <hi.wen.chen <at> gmail.com>
To: pegasus-l <at> opengroup.org
Sent: Thursday, May 31, 2007 7:17:51 PM
Subject: indication subscrition persistence across cimserver restart

Hi,

I am using Pegasus 2.6.

I have noticed these subscription persistence behaviors during cimserver restart:

1. indication filters, handlers, and subscriptions survive cimserver restart.

2. cimserver does not call the enable/create/modifySubscription methods on providers after a restart, so that providers will not know if there are pre-existing subscriptions in the system.

The above behaviors contradict each other¢s design intentions. What¢s your approach for your providers to recognize pre-existing subscriptions?

Thanks,

Wen

Karl Schopmeyer                   Inova Europe Inc.
305 Spring Creek Village, Suite 475 - DallasTX, 75248USA
EMAIL: k.schopmeyer <at> swbell.net       FAX: 1-972-239-0326
Phone: 1-972-788-2172,          Cell Phone 1-972-814-5581
Skype: kschopmeyer         Skype Phone: (214) 556-5971

headers

aiyer_kamesh | 1 Jun 2007 22:30

RE: indication subscrition persistence across cimserver restart

The CIM schema does not provide any way to indicate that a subscription is persistent. Pegasus chose to take a property of a subscription (that specified that it was an Error for a listener to fail) and interpret it as a persistent subscription.

At this point, it is CIMOM-specific behavior whether a particular subscription is persistent over server restarts or not, and what it means to be persistent (does the provider get asked if it was still able to support the filter or does the server assume that the provider's capabilities have not changed).

I think the design needs to be worked out through DMTF's Indication profile authoring subgroup.

Cheers,

-- Kamesh

From: Wen Chen [mailto:hi.wen.chen <at> gmail.com]
Sent: Friday, June 01, 2007 3:58 PM
To: 'Kirk Augustin'; 'Karl Schopmeyer'; pegasus-l <at> opengroup.org
Subject: RE: indication subscrition persistence across cimserver restart