Thanks for the quick response. I attached the source code to the TrapListener to give you a better idea of what is going on. It looks like the second scenario is happening, so I will definstance each trap as they come in. You mentioned that I could undefinstance them in a rule to get rid of them. How would I ensure that I do not get rid of the definstance before all the rules have had a chance to "see" the event. Would this be an appropriate situation to use salience (if I recall correctly, the documentation recommends using salience sparingly). Ideally, I would like to keep the events around for some specified amount of time, because I will eventually need to correlate multiple events (within recent history) with the rules. What would be the best way to do this with a rule? Thanks, Grant > >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On >Behalf Of [EMAIL PROTECTED] >Sent: Tuesday, September 19, 2000 8:43 AM >To: Grant Jokerst >Cc: [EMAIL PROTECTED] >Subject: Re: JESS: Issues with incoming asynchonous events > > > >The problem is that the count field is changing faster than Jess can >keep up. This can happen if the PropertyChangeEvents don't specify the >name of the changed field or the new value. Under these circumstances, >Jess has to fetch the new property value from the bean itself, and if >the property is changing rapidly, this will obviously give rise to the >behaviour you're seeing. Make sure your PropertyChangeEvents specify >"count" for the name, and an Integer object with the new value for the >new-value field, and you shouldn't see this happening. > >Another possibility arises when the above conditions are met, but the >engine is running on one thread while the change notifications are >coming on another (as is usually the case) and the events are simply >coming so fast that the change-thread is starving the run-thread -- >i.e., changes are occurring faster than activations can fire. Since >you've got this single trap object, whenever the count increases, any >old activations are removed and a new one is created, so old ones are >simply being skipped; this is how you've defined the problem. > >To fix this, you need an architectural change. You could definstance >the network event objects themselves as they arrive; then each one >could hang around in the Rete network as long as it took to be >processed. A rule could be responsible for undefinstancing each event >after it was recorded. Alternatively, the trap could create a regular >Jess fact to represent each network event and assert it, if for some >reason definstancing the event objects themselves is not feasible or >desirable. > >I think Grant Jokerst wrote: >[Charset iso-8859-1 unsupported, filtering to ASCII...] >> Hello all, >> I am new to Jess and I am trying to use it to apply rules against network >> events (such as SNMP traps). I have been able to apply rules to the events >> by placing the events in a Queue and modifying a count property in a >> TrapListener class. The TrapListener class uses a PropertyChangeSupport >> object to notify Jess of changes to the count (via firePropertyChange) >> similiar to the "jess/examples/simple/Simple.java" code. The rules work >> fine as long as multiple events do not come in at the same time. However, >> if events come in rapidly (which is generally the case with network events), >> the rule "new-event" does not always fire. I have tried various >> synchronization techniques to no avail. >> >> The rules look something like: >> .... >> (deftemplate jobject (slot class) (slot OBJECT)) >> (defclass traplstn TrapListener extends jobject) >> (defclass trapd Trapd extends jobject) >> >> ;; This rule will fire any time an event comes in and prints out the count >> (defrule new-event >> (traplstn (count ?count) ) >> => >> (printout t "ALERT: received trap, count is " ?count crlf) >> ) >> >> (defrule startup >> => >> ;; Instantiate the daemon >> (definstance trapd (bind ?thetrapd (new Trapd))) >> ;; Instantiate a listener to the daemon which queues up the traps >> (definstance traplstn (bind ?thetraplstn (new TrapListener))) >> ;; Add the queue from the TrapListener for thetrapd to send >> ;; The count is incremented and set every time an event comes in. >> (call ?thetrapd addListener (?thetraplstn getQueue)) >> ) >> >> (reset) >> ;; we must "run-until-halt" b/c there will be nothing on the agenda >> ;; until an event comes in >> (run-until-halt) >> ...... >> >> Ideas, anyone? >> >> Thanks, >> Grant >> >> --------------------------------------------------------------------- >> To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' >> in the BODY of a message to [EMAIL PROTECTED], NOT to the >> list (use your own address!) List problems? Notify [EMAIL PROTECTED] >> --------------------------------------------------------------------- >> > > > >--------------------------------------------------------- >Ernest Friedman-Hill >Distributed Systems Research Phone: (925) 294-2154 >Sandia National Labs FAX: (925) 294-2234 >Org. 8920, MS 9012 [EMAIL PROTECTED] >PO Box 969 http://herzberg.ca.sandia.gov >Livermore, CA 94550 >--------------------------------------------------------------------- >To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' >in the BODY of a message to [EMAIL PROTECTED], NOT to the >list (use your own address!) List problems? Notify [EMAIL PROTECTED] >---------------------------------------------------------------------
<<< java/*; name=TrapListener.java: Unrecognized >>>
