Wen Chen | 1 Jun 04:17 2007
Picon

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

Kirk Augustin | 1 Jun 05:55 2007
Picon

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

<!-- _filtered {font-family:SimSun;panose-1:2 1 6 0 3 1 1 1 1 1;} _filtered {panose-1:2 1 6 0 3 1 1 1 1 1;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;font-family:"Times New Roman";} a:link, span.MsoHyperlink {color:blue;text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:purple;text-decoration:underline;} span.EmailStyle17 {font-family:Arial;color:windowtext;} _filtered {margin:1.0in 1.25in 1.0in 1.25in;} div.Section1 {} -->

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


Padmanabhachar, Dhananjaya | 1 Jun 08:32 2007
Picon

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.

 

 

 

 

 

Michael E. Brasher | 1 Jun 15:57 2007
Picon

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

Karl Schopmeyer | 1 Jun 17:38 2007
Picon

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


Kirk Augustin | 1 Jun 21:06 2007
Picon

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



Wen Chen | 1 Jun 21:58 2007
Picon

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

 

aiyer_kamesh | 1 Jun 22:30 2007

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

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

 

Houston, Eddie | 1 Jun 23:05 2007
Picon

RE: indication subscrition persistence across cimserver restart

If a client calls the createInstance method which succeeds and creates a CIM instance, it concerns me that there is the possibility that that instance may no longer exist when the CIM Server is restarted.

 

Regards,

Eddie

From: aiyer_kamesh <at> emc.com [mailto:aiyer_kamesh <at> emc.com]
Sent: Friday, June 01, 2007 1:31 PM
To: hi.wen.chen <at> gmail.com; kirk_augustin <at> yahoo.com; k.schopmeyer <at> swbell.net; pegasus-l <at> opengroup.org
Subject: 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

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

 

Eckstein, Denise Marie | 2 Jun 00:04 2007
Picon

RE: indication subscrition persistence across cimserver restart

Hi Wen,
 
You might find the cimsub utility helpful in triaging this problem.  It was introduced in 2.6. Documentation is available in PEP257.
 
 
Denise

From: Wen Chen [mailto:hi.wen.chen <at> gmail.com]
Sent: Friday, June 01, 2007 12:58 PM
To: 'Kirk Augustin'; 'Karl Schopmeyer'; pegasus-l <at> opengroup.org
Subject: 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

 


Gmane