Perl - multiple observers for different sessions

Hi Christian,

interesting ... bug ? ... to meet your requirement, I'm used to do stuff within the DXA (to act when notifications come in) and then using an external adapter (like the one you are using) to act on notifications' changes. So I never saw this situation, but I would think this is a bug.

Now, to have a workaround: regarding your requirements, can you just subscribe to SAM and not from IP ? : you will still have Host's notifications (after the smoothing interval ... which can be better / worst depending of your needs) coming in, and you should be able to count them based on whatever the criteria is and create new notifications within the SAM.

HTH,

--Fred

Hi Fred,

thanks for reply.

I dont think that "wating" for an event before waiting for the next observers event is a bug.

As per perl API documentation

The receiveEvent() method can take an optional parameter to specify a timeout in seconds, which may be fractional. If no event arrives within the specified time, a pseudo-event of type TIMEOUT is returned. For example, @event = $observer->receiveEvent( 0.25 ); If no timeout is specified, the call waits forever.

I think my problem can be solved when I can check for an event on observerSAM OR observerIPM.

my @event =  $observer_SAM->receiveEvent(0.25) || $observer_IPM>receiveEvent(0.25) ;

I guess I'll stick on that for now to see what happens. Maybe just setting timeout for SAM to 60 and IPM to 30 seconds.. this should lead to seeing timeouts from IPM instead of SAM in case no event is received on either one.

Anyway, did not get the point how I can utilize DXA for that.

The script needs to run permanently as the counter will be increased or decreased in loop while events are received. From how I understand that, you want me to invoke an automated tool what gets the down hosts handed over and this script should "update" my deamonized script ?

If so, then I need to open a socket to write to what means building a client-server solution ? Of course, this would prevent from running observers on the particular hosts as Smarts will do this automagically. But then I still have to observe the notifications for acknowledge somehow.

Would you be so kind to be more specific on your suggestion ?

Thanks in advance.

Regards Christian

Maybe I found what I was searching for: "select"

@ret = InCharge::session::select(\@observerList, $timeout); The select() function checks if there are data to be read for each observer in @observerList.

Unfortunately it seems to not work on SAM 7.2 / IPM 7.0.3 (stolen from newest perl API documentation as the old ones are some kind of.. )

Can't locate object method "flowReadableNow" via package "IO::Socket::INET" at /opt/SMARTS/InCharge/IP/smarts/local/perl/5.8.8/lib/InCharge/session.pm line 2907, line 3

None of the INET.pm found on the system contains a "flowReadableNow".

What I also found was a "getFileNo"

Thats what I want:

$fno = $session->getFileno( ); Returns the underlying system file number that refers to the socket used for the script/server connection. This is useful when the script wishes to use the Perl select statement to listen for events from multiple domain servers, using multiple observer objects.

But...

Note: Do not use this function with the Perl select statement to listen for events from multiple domains by using multiple observer objects. Instead, use the new select function: InCharge::session::select.

So "select" is the new function.. a new function that most propably was implemented to work around a more complex way to receive events from more than one observer using "getFileNo" in the past ? If, how was this implemented ?  Somebody knows ?

Thanks

Christian

Well, I don't have all the answers, but I do have some:

1. The getFlowFileno (which replaced fileno) is actually part of remote.pm and was added as a series of extensive changes to support Perl 5.8.8

2. The package for IP started including that same functionality in HF 18.  For IP, the "sub select" was added to session.pm at the same time as the addition of getFlowFileno.

3. Other than some rather vague comments around "Perl API" updates, there is no indication of a known problem surrounding the addition of that function.  I will continue to do some digging and see what I come up with.

--Bill

Hi Christian,

I see now. Sorry, I misread your statement regarding the delay. Your issue is that "receiveEvent" blocks (so you don't have to loop over it again and again). You will have to go into non-blocking mode for that, as you would do with sockets, and yes "select" should be the way to go. I don't know how to do this with the InCharge API, but I've already done that with PERL/select for IP sockets and yes it works. You have to consumme the first "channel" receiving stuff.

Regarding the suggestion I've made to workaround this subcription to both IP and SAM at the same time:

- you mentioned you need to count the number of hosts Down, for that you are subscribing to IP,

=> my proposal is to subscribe to SAM (ICS_NotificationList, configured to only take into account the Host::.*::Down for example)

    - you still have all the IP down "event" (now ICS_Notification within SAM) except the fact that the notifications will appear after the smoothing interval, not realtime as when you subscribe to IP directly, (but this may be a requirement)

- you mentioned you need to do some processing based on these "events" (now notifications in my case) and create a new notification

=> you can also do that directly in the SAM with the session you have

Only one connection to the SAM. Only one subscriber to the ICS_NotificationList (better than ICS_Notification). Should meet your requirements.

HTH,

--Fred

Thanks for the reply Bill,

despite I think I'll rather stick on Freds suggestions, I may have a "problem" with my "smarts perl" at all.

I copied the snipplet from perl API documentation regarding select but don't get it to work. It always exits with:

# sm_perl test.pl Can't locate object method "flowReadableNow" via package "IO::Socket::INET" at /opt/SMARTS/InCharge/SAM/smarts/local/perl/5.8.8/lib/InCharge/session.pm line 2907, line 3.

So i just grepped all "sub" from this package and I don't see a sub called that.

# grep sub /opt/SMARTS/InCharge7/SAM/smarts/local/toolbox/perl/lib/5.8.8/IO/Socket/INET.pm sub new { sub _sock_info { sub _error { sub _get_addr { sub configure { sub connect { sub bind { sub sockaddr { sub sockport { sub sockhost { sub peeraddr { sub peerport { sub peerhost {

Just in case I'll need it in the future, may you advise what to check for ?

SunOS smarts03 5.10 Generic_138888-03 sun4u sparc SUNW,Sun-Fire-V215

SAM_SUITE: V7.2.0.21(95444), 21-Jan-2010 07:52:11 Copyright 1995-2010, EMC Corporation - Build 82
Foundation V7.2.0.1(95417), 20-Jan-2010 04:59:41 Copyright 1995-2010, EMC Corporation - Build 100

IP_NETWORK_SUITE: V7.0.3.27(98320), 21-May-2010 05:24:55 Copyright 1995-2010, EMC Corporation - Build 191
Foundation V7.0.2.1(97509), 17-Apr-2010 09:58:46 Copyright 1995-2010, EMC Corporation - Build 97

# which sm_perl
/opt/SMARTS/InCharge/SAM/smarts/bin/sm_perl

^^ Maybe that's the problem, alternative was not updated by the patches introduced perl 5.8.8 ? I have a "full blown" sm_perl binary located in /opt/SMARTS/InCharge7/SAM/smarts/local/bin/system/ while sm_perl above is just a symlink to runcmd.

As I cant attach a file here and I won't blow this up that much I can also open a case for that if you want me to do. Or just send you the output from "sm_perl -V" via mail if you want to.

Thanks

Christian

And also thank you Fred for the response .

Yes, receiveEvent blocks due to its timeout as each waits until it throws a timeout before invoke the next one. It woult simply stock n case I dont' define this.

Unfortunately it seems that I miss notifications while waiting, even with 1 second.

I do loop over and over (see while (1) - loop in my snipplet above) as this is needed as far as I understand how it works.

What do you mean with "non blocking mode" ? How to achive this ?

What I meant with "failure in design" is exaclty what you described. As smoothing intervall or even realtime is not that important I can of course just only connect to SAM and deal with the notifications I receive there. Thanks for pointing that out.

I simply have to build my notificationlist with the subscribe() feature. The data I need from the IPM I can get with single requests to a certain attribute.

So my problem (as far as I get it done with SAM only what I expect) seems to be solved here, except that select does not seem to work for me as you can read in the post above.

Despite that and just for learning purposes, may you sent/post me a sniplet how you dealed with the sockets ?

Thanks

Christian

Christian,

     The line showing flowReadableNow as part of IO::Socket::INET is a bit of a red herring.  It is actually part of InCharge::FlowWrapper::FlowAPI (FlowWrapper.pm).  This is actually the first point by which C++ code was introduced into the Perl API.  Up to that point, the implementation of the protocol stack was native Perl.  However, to introduce session encryption and keepalives to Perl (and thus bring it on-par with other APIs), that code was introduced.  I suspect that this was the point where "sub select" was also introduced.

     I suspect that your using a mixed bag of components might be throwing things off here.  Interestingly, sm_perl is never "real".  All that it does is setup some environmental variables to make running within our environment easier and then calls a "real" perl interpreter.  The sm_perl.options file actually controls which Perl actually gets executed in the system.  I would suggest that for consistency you may want to use a common Perl across those systems instead of relying on the one that might be shipped with the product.  Adjust the sm_perl.options to point to that one and at least know what you are using.

--Bill

Hi Bill,

as we (or more precise: EMC) migrated our installtion from 6.x to 7.x (SAM/IPM) the perl api was simply not working correctly. Therefore they disabled flowwrapper.

$ export | grep FLOW declare -x SM_DISABLE_FLOW_WRAPPER="1"

As you pointed to this, maybe the problem is located here as we are missing some fundamental things here ?

Btw: It does not matter if I invoke sm_perl or perl directly, the error is the same.

$ which sm_perl /opt/SMARTS/InCharge/SAM/smarts/bin/sm_perl $ ls -al /opt/SMARTS/InCharge/SAM/smarts/bin/sm_perl lrwxrwxrwx   1 root     root           6 Oct 15  2008 /opt/SMARTS/InCharge/SAM/smarts/bin/sm_perl -> runcmd $ ls -al /opt/SMARTS/InCharge/SAM/smarts/bin/runcmd -r-xr-xr-x   1 root     root       21205 Feb 14 16:48 /opt/SMARTS/InCharge/SAM/smarts/bin/runcmd

The most actual runcmd I can find on the system refers to

-r-xr-xr-x   1 root     root       20012 Apr 17 15:58 /opt/SMARTS/InCharge7/IP/smarts/local/bin/runcmd

For me it seems it makes most sense to use sm_perl pointing to this one. Would you agree ?

Rgds

Christian