Christof, what exactly do you mean by state awareness -- do you mean the ability to restore contexts, event correlation operations, and other event correlation state? Unfortunately, there can be no generic solution to this, since event correlation state is tightly tied with time. For example, contexts have a lifetime and some of them could have expired long time ago -- which raises a question whether their action-on-expiration lists should be executed or not. As for another example, keys of event correlation operations contain rule file names -- but what if a file is removed between stop and restart?
Having said this, it is nevertheless possible to retain *some* state between shutdown and restart, but *what* state gets saved and *how* this is used after restart must be defined by the user. In order to guide you to one example, here is an interesting discussion from the mailing list: http://sourceforge.net/mailarchive/message.php?msg_id=4177CC7F.7080002%40eyp.ee HTH, risto On 12/02/2009 09:30 AM, Schmid, Christof wrote: > > Hi Risto > > I did not try it with CygWin yet because at the moment we are running sec in > a purely SunOS environment. However I've another question about the state > awareness of sec after reloading its configuration file. I think this is a > rather sophisticated issue and therefore wanted to ask if there is a > documentation available on this topic? > > > > -----Original Message----- > From: Risto Vaarandi [mailto:risto.vaara...@seb.ee] > Sent: Montag, 30. November 2009 17:05 > To: simple-evcorr-users@lists.sourceforge.net > Subject: Re: [Simple-evcorr-users] SEC: limited number of characters in input > stream? > > On 11/30/2009 05:12 PM, Schmid, Christof wrote: >> >> Hi Risto >> >> Indeed this seems to have been the problem :) However I still don't >> understand the difference between the command line input which seems to be >> unlimited and the sec input which is restricted to 256 characters. > > BTW, I noticed from the screenshot that you are running SEC with ActiveState > Perl -- however, the past versions of ActiveState were known for their > insufficient emulation of UNIX environment (which meant that some essential > SEC features were not working properly). > > Have you tried to run SEC with CygWin Perl instead? I don't have much > experience with this Perl release, but several list members have used SEC on > top of CygWin quite successfully. > > hth, > risto > >> >> >> Thank you for your efforts! >> >> >> Regards >> >> Christof >> >> >> -----Original Message----- >> From: Risto Vaarandi [mailto:risto.vaara...@seb.ee] >> Sent: Montag, 30. November 2009 14:03 >> To: Schmid, Christof >> Cc: Risto Vaarandi; Sonderegger, Markus; >> simple-evcorr-users@lists.sourceforge.net; Gasser, Bruno >> Subject: Re: [Simple-evcorr-users] SEC: limited number of characters in >> input stream? >> >> Christof, >> I understand now what you meant by SEC not accepting more than certain >> amount of characters. This is not a SEC issue, but a Windows issue -- it is >> known that certain Windows flavors (esp. Windows NT boxes) limit the size of >> a command line to 256 characters. Although I am not much of a Windows >> expert, I strongly suspect that you can't type more bytes because of this OS >> restriction. >> On Linux (or any other UNIX system) there are no such limitations and you >> can easily type in more than 256 bytes. >> with kind regards, >> risto >> >> On 11/30/2009 01:28 PM, Schmid, Christof wrote: >>> Hi Risto >>> Thank you for the quick answer. The input event is provided through >>> the keyboard. After calling "sec.pl >>> -conf=/bcom1/mqsi/SEC/sessionMonitor.conf -input=-" I can write >>> exactly >>> 257 characters until no more input is accepted (there is no error >>> message, but simply no reaction) except linefeed or ^C.. >>> >>> --------------------------------------------------------------------- >>> - >>> -- >>> *From:* Risto Vaarandi [mailto:rvaara...@yahoo.com] >>> *Sent:* Montag, 30. November 2009 12:22 >>> *To:* Schmid, Christof >>> *Cc:* simple-evcorr-users@lists.sourceforge.net; Sonderegger, Markus; >>> Gasser, Bruno >>> *Subject:* RE: SEC: limited number of characters in input stream? >>> >>> hi Christof, >>> would it be possible to provide sample input in text format? It is >>> impossible for list members to test your input from a pic file. >>> Another question -- you mentioned in your previous mail that SEC is >>> reading events from standard input. How exactly are the input events >>> provided? If the are sent in via regular UNIX pipe, it could well be >>> that the writing application has opened the pipe in non-blocking mode >>> which could result in data loss. >>> kind regards, >>> risto >>> >>> --- On *Mon, 11/30/09, Schmid, Christof >>> /<christof.sch...@juliusbaer.com>/* wrote: >>> >>> >>> From: Schmid, Christof<christof.sch...@juliusbaer.com> >>> Subject: RE: SEC: limited number of characters in input stream? >>> To: "Risto Vaarandi"<rvaara...@yahoo.com> >>> Cc: simple-evcorr-users@lists.sourceforge.net, "Sonderegger, Markus" >>> <markus.sondereg...@juliusbaer.com>, "Gasser, Bruno" >>> <bruno.gas...@juliusbaer.com> >>> Date: Monday, November 30, 2009, 11:57 AM >>> >>> >>> Risto >>> >>> No, my data does not contain linefeed characters. In the printscreen >>> below you find an example with printable characters {0..9}. Just >>> after a few hundred numbers it is not possible to input any further >>> data (at this point, only new line or ^C is accepted as input). By >>> contrast, on the normal unix command line the number of characters >>> is unlimited (see below: the green cursor does not mark the end of >>> the input stream, I could still add more characters). So there >>> cannot be a restriction on unix level either. I also tried to change >>> the blocksize and bufsize parameters but it didn't help.. >>> >>> Picture (Device Independent Bitmap) >>> >>> >>> -----Original Message----- >>> From: Risto Vaarandi [_mailto:rvaara...@yahoo.com_] >>> Sent: Freitag, 27. November 2009 15:52 >>> To: Schmid, Christof >>> Cc: Sonderegger, Markus >>> Subject: Re: SEC: limited number of characters in input stream? >>> >>> Christof, >>> in the SEC code, there are no such limits for reading incoming >>> lines. In fact, the code does not process a line from its input >>> buffer until the newline character (ASCII 10) has been seen. Over >>> the years, the users have used standard input for sending fairly >>> large events to SEC. >>> >>> What sort of input are you trying to match? Is it possible that the >>> data contains ASCII 10 characters? >>> Also, could you post more detailed questions to the SEC mailing >>> list? In that way, other users can benefit from the discussion as >>> well. >>> >>> BR, >>> risto >>> >>> --- On Fri, 11/27/09, Schmid, Christof >>> <christof.sch...@juliusbaer.com> wrote: >>> >>> > From: Schmid, Christof<christof.sch...@juliusbaer.com> >>> > Subject: SEC: limited number of characters in input stream? >>> > To: rvaara...@yahoo.com >>> > Cc: "Sonderegger, Markus"<markus.sondereg...@juliusbaer.com> >>> > Date: Friday, November 27, 2009, 1:52 PM >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > Hi >>> > Risto >>> > >>> > I've a problem >>> > concerning the Simple Event Correlator. When I call "perl sec.pl >>> > -conf=sessionMonitor.conf -input=- -log=SecSessionMonitor.log >>> > -debug=6", the command line expects user input. However the >>> number of >>> > characters in this input stream is limited to 157 per line. Do >>> you >>> > know the reason why? Is there a way to avoid this limitation? >>> I've >>> > observed the same behaviour with a file input stream. >>> > >>> > >>> > Regards >>> > >>> > >>> > Christof >>> > Schmid >>> > >>> > >>> > ______________________________________________________________ >>> > Christof Schmid >>> > MSc ETH in Computer Science >>> > Application and >>> > Development Services (PTDA) >>> > Bank Julius Baer& Co. Ltd. >>> > P. O. Box, >>> > CH-8010 Zürich, Switzerland >>> > Phone +41 (0) 58 887 44 89, Mobile +41 (0) 79 230 >>> > 29 35 >>> > christof.sch...@juliusbaer.com, >>> > >>> > _www.juliusbaer.com_ >>> > ______________________________________________________________ >>> > >>> > >>> > *****JuliusBaer Disclaimer***** >>> > This e-mail is for the intended recipient only and may contain >>> > confidential or privileged information. If you have received this >>> > e-mail by mistake, please contact us immediately and completely >>> delete >>> > it (and any attachments) and do not forward it or inform any >>> other >>> > person of its contents. If you send us messages by e-mail, we >>> take >>> > this as your authorization to correspond with you by e-mail, >>> however, >>> > we will not accept the electronic transmission of >>> orders/instructions >>> > without a specific agreement being in place to govern the same. >>> If >>> you >>> > do not wish to receive any further e-mail correspondence please >>> let us >>> > know. E-mail transmission cannot be guaranteed to be secure or >>> > error-free as information could be intercepted, amended, >>> corrupted, >>> > lost, destroyed, arrive late or incomplete, or contain viruses. >>> > Neither the Julius Baer Group nor the sender accept liability >>> for any >>> > errors or omissions in the content of this message which arise >>> as a >>> > result of its e-mail transmission. Please note that all e-mail >>> > communications to and from the Julius Baer Group may be >>> monitored. >>> > This communication is for informational purposes only. It is not >>> > intended as an offer or solicitation for the purchase or sale of >>> any >>> > financial instrument or as an official confirmation of any >>> > transaction. >>> > >>> > >>> >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> - >>> -------- Let Crystal Reports handle the reporting - Free Crystal >>> Reports 2008 30-Day trial. Simplify your report design, integration >>> and deployment - and focus on what you do best, core application >>> coding. Discover what's new with Crystal Reports now. >>> http://p.sf.net/sfu/bobj-july >>> >>> >>> >>> _______________________________________________ >>> Simple-evcorr-users mailing list >>> Simple-evcorr-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users >> >> ---------------------------------------------------------------------- >> -------- Let Crystal Reports handle the reporting - Free Crystal >> Reports 2008 30-Day trial. Simplify your report design, integration >> and deployment - and focus on what you do best, core application >> coding. Discover what's new with Crystal Reports now. >> http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Simple-evcorr-users mailing list >> Simple-evcorr-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users >> >> > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with Crystal > Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Simple-evcorr-users mailing list > Simple-evcorr-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users > > ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ Simple-evcorr-users mailing list Simple-evcorr-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
