List Info

Thread: Possible deadlock problem with update in place rules
Possible deadlock problem with update in place rules
country flaguser name
United States		 2008-02-28 10:55:56 

  


  

    





I use a Ruleagent with the following params



(rules.properties):



localCacheDir=…



url=…;



poll=30



name=eventexpertrules



 



Here is my session initialization:




 



RuleAgent agent =
RuleAgent.newRuleAgent("/rules.properties";);




RuleBase retValue = agent.getRuleBase();



final RuleBase ruleBase = agent.getRuleBase();



session = ruleBase.newStatefulSession();



DroolsLogger drlogger = new DroolsLogger(session); // add
logger           



//Insert Event Processor Instance as global



session.setGlobal("processor", this);



 



 



Here is the stack trace of the thread that updates the rule base




 



"Timer-2" daemon prio=3 tid=0x0000000002356800 nid=0x24
waiting for monitor entry [0xfffffd7fe28b7000..0xfffffd7fe28b7a20]



   java.lang.Thread.State: BLOCKED (on object monitor)



        at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:433)



 &nbsp; &nbsp; &nbsp;  - waiting to lock <0xfffffd7feb474680> (a
org.drools.reteoo.ReteooStatefulSession)



 &nbsp; &nbsp; &nbsp;  at
org.drools.base.FireAllRulesRuleBaseUpdateListener.beforeRuleBaseUnlocked(FireAllRulesRuleBaseUpdateListener.java:29)



 &nbsp; &nbsp; &nbsp;  at
org.drools.event.RuleBaseEventSupport.fireBeforeRuleBaseUnlocked(RuleBaseEventSupport.java:168)



 &nbsp; &nbsp; &nbsp;  at
org.drools.common.AbstractRuleBase.unlock(AbstractRuleBase.java:351)



 &nbsp; &nbsp; &nbsp;  at org.drools.agent.PackageProvider.applyChanges(PackageProvider.java:73)




 &nbsp; &nbsp; &nbsp;  at
org.drools.agent.RuleAgent.refreshRuleBase(RuleAgent.java:320)



 &nbsp; &nbsp; &nbsp;  at
org.drools.agent.RuleAgent$2.run(RuleAgent.java:438)



 &nbsp; &nbsp; &nbsp;  at
java.util.TimerThread.mainLoop(Timer.java:512)



 &nbsp; &nbsp; &nbsp;  at
java.util.TimerThread.run(Timer.java:462)



 



 



Here is the stack trace of my application
that basically inserts facts and fires rules …



 



"ActiveMQ Session Task" daemon
prio=3 tid=0x0000000002564400 nid=0x142e in Object.wait() [0xfffffd7fe01dd000..0xfffffd7fe01ddaa0]



 &nbsp; java.lang.Thread.State:
WAITING (on object monitor)



 &nbsp; &nbsp; &nbsp; 
at java.lang.Object.wait(Native Method)



 &nbsp; &nbsp; &nbsp; 
- waiting on <0xfffffd7feb49a9e0> (a
org.drools.util.concurrent.locks.ReentrantLock$NonfairSync)



 &nbsp; &nbsp; &nbsp; 
at java.lang.Object.wait(Object.java:485)



 &nbsp; &nbsp; &nbsp; 
at
org.drools.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:106)




 &nbsp; &nbsp; &nbsp; 
- locked <0xfffffd7feb49a9e0> (a
org.drools.util.concurrent.locks.ReentrantLock$NonfairSync)



 &nbsp; &nbsp; &nbsp; 
at org.drools.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:195)



 &nbsp; &nbsp; &nbsp; 
at
org.drools.common.AbstractWorkingMemory.getGlobal(AbstractWorkingMemory.java:397)



 &nbsp; &nbsp; &nbsp; 
at
com.daxtechnologies.optima.fault.eventprocessor.Rule_EventForwarder_0ConsequenceInvoker.evaluate(Unknown
Source)



 &nbsp; &nbsp; &nbsp; 
at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:550)




 &nbsp; &nbsp; &nbsp; 
- locked <0xfffffd7feb49a3f8> (a org.drools.common.DefaultAgenda)



 &nbsp; &nbsp; &nbsp; 
at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:514)




 &nbsp; &nbsp; &nbsp; 
at
org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:471)



 &nbsp; &nbsp; &nbsp; 
- locked <0xfffffd7feb474680&gt;
(a org.drools.reteoo.ReteooStatefulSession)



 &nbsp; &nbsp; &nbsp; 
at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:433)



 
&nbsp;   ; &nbsp;- locked <0xfffffd7feb474680> (a
org.drools.reteoo.ReteooStatefulSession)



 &nbsp; &nbsp; &nbsp; 
at
com.daxtechnologies.optima.fault.eventprocessor.fault.level2.maps.EventExpertProcessor.processEventVO(EventExpertProcessor.java:147)



 &nbsp; &nbsp; &nbsp; 
- locked <0xfffffd7feb474a18> (a
com.daxtechnologies.optima.fault.eventprocessor.fault.level2.maps.EventExpertProcessor)



 &nbsp; &nbsp; &nbsp; 
at
com.daxtechnologies.optima.fault.eventprocessor.fault.level2.maps.EventExpertProcessor.doProcessEvent(EventExpertProcessor.java:70)




 



 



As you see both threads wait for something&#8230;



 



thanks



 



--zoly



 






  

  
  
   
     
    

  

     Drools JBRMS vulnerability to
"JavaScript Hijacking" (or
hopefully lack of thereof)
  


  

     country flaguser name
United States		
     2008-02-29 15:37:17
  


  

    

  


  

    



I got a request today to 
verify that the Drools JBRMS is not vulnerable to "JavaScript Hijacking" - a 
term coined by Fortify Software in an article in March 2007 where they note that 
GWT is vulnerable to JavaScript Hijacking if some default behaviors are changed. 



 


Based on the research I've 
done so far, I don't think this is the case, but am posting to the list to see 
if someone more knowledgeable on the JBRMS than myself (wouldn't take much) has 
considered this issue.


 


Here's why I don't think the 
JBRMS is vulnerable:


 


1.  The Fortify 
Software article says you need to use HTTP GET requests to be vulnerable.  
GWT's default behavior is to use HTTP POST requests, and I only found POST 
requests in the GWT-compiler-generated HTML files for version 
4.0.4.


 


2.  The Fortify 
Software article says you can be vulnerable if you use JSON. ; I don't see 
any ;instances of JSON in the JBRMS source code - as best as I 
can ;tell from Google's GWT documentation, you would use their 
JSONParser class if you were doing this(http://groups.google.com/group/Google-Web-Toolkit/web/security-for-gwt-applications).


 


I'm posting to the list 
because I didn't see any drools-jbrms JIRA issues regarding 
security.


 



Thanks,


Dave 
Warren

  

  
  
   
     
    






 [1-2]











   
 





about | contact  Other archives ( Real Estate discussion Medical topics )