Re: [rules-users] Multi Access to Stateful Session

The propositions were meant to investigate the possibility of some synchronization problem in Drools. However. For embedding Drools in a multi-threaded application with several threads needing to insert facts I'd probably still go for Drools being run by one or two threads, with a BlockingQueue for feeding facts to the (single) thread doing insertions. Either call fireAllRules() whenever the queue is empty (peek()==null) or use fireUntilHalt() in another thread. (I'd go for the first options. It dissolves all synchronization issues...) -W On 03/04/2012, gboro54 &lt;gboro54@&gt; wrote: > I will give these a try although they would seem to defeat the purpose of > having the ability to have a session always up and running already > evaluation. Another thought I had was to get rid of the list of > deregistered > positions and instead create a lightweight fact which would just get > created > an inserted(i.e DeregisteredMessageFact). This would allow the single > threaded session to own the controller completely. Does this sound like a > reasonable approach to the problem? > > > laune wrote >> >> Another poster on this list has stated that there are flaws in the >> synchronization of Drools, but IIRC this was related to an older >> version. >> >> I can propose two additional experiments: >> >> (1) Have you ever run this with insertions from a single thread, and >> with >> the >> engine being run in one other thread? >> >> (2) Run an experiment where you call fireAllRules() after each >> insertion, with insertions from multiple threads. >> >> -W >> >> >> On 02/04/2012, gboro54 &lt;gboro54@&gt; wrote: >>> I updated the MessageControl fact as follows and the same issue still >>> occurs: >>> >>> private Long currentPosition = new Long(0); >>> private Set<Long> excludedPositions = new HashSet<Long>(); >>> >>> public synchronized void addPositionToExclusionList(Long position) { >>> excludedPositions.add(position); >>> } >>> >>> public synchronized Long getCurrentPosition() { >>> return currentPosition; >>> } >>> >>> public synchronized void moveCurrentPositionForward(Integer value) { >>> currentPosition += value; >>> if (currentPosition % 20000 == 0) { >>> System.out.println(currentPosition); >>> } >>> >>> } >>> >>> public synchronized boolean atExcludedPosition() { >>> return excludedPositions.contains(currentPosition); >>> } >>> >>> Not sure what else could occur between the insertions and the rule >>> execution >>> that would be an issue... >>> >>> >>> laune wrote >>>> >>>> So it looks like a race condition. >>>> >>>> There is one chink in the snchronizing armour of class MessageControl. >>>> The Map excludedPositions (although in itself synchronized on its own >>>> lock) is exposed via the getExcludedPositions. Thus, synchronization >>>> between currentPosition and excludedPositions is broken. I can't say >>>> whether this matters, but just try and add delegating methods to >>>> MessageControl and remove getExcludedPositions. (And use a plain >>>> HashSet - synchronization is provided by MessageControl.) >>>> >>>> Obviously, rules will have to use something like >>>> atExcludedPosition == true >>>> when the Map is fully privatized. >>>> >>>> -W >>>> >>>> >>>> On 02/04/2012, gboro54 &lt;gboro54@&gt; wrote: >>>>> A gap would have to occur somewhere but I am not sure how or why. >>>>> Since I am using the same data for each test case, the outcome should >>>>> be the same but 75% of the time to position stops at a random point >>>>> and thus allows messages to backup in memory >>>>> >>>>> On Mon, Apr 2, 2012 at 12:19 PM, laune [via Drools] >>>>> &lt;ml-node+s46999n3878174h55@.nabble&gt; wrote: >>>>>> What is the current position value in the controller when it blocks? >>>>>> A >>>>>> regular message rank or one of those not to be processed or both? >>>>>> >>>>>> Are you sure that message ranks are increasing without gaps except >>>>>> those in the excluded position map? >>>>>> >>>>>> -W >>>>>> >>>>>> On 02/04/2012, gboro54 <[hidden email]> wrote: >>>>>> >>>>>>> Forgo to mention each time a position is added to the excluded >>>>>>> position >>>>>>> map, >>>>>>> the insertOrUpdate method is called on the session wrapper. >>>>>>> >>>>>>> -- >>>>>>> View this message in context: >>>>>>> >>>>>>> http://drools.46999.n3.nabble.com/Multi-Access-to-Stateful-Session-tp3877... >>>>>>> Sent from the Drools: User forum mailing list archive at >>>>>>> Nabble.com. >>>>>>> _______________________________________________ >>>>>>> rules-users mailing list >>>>>>> [hidden email] >>>>>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>>>>> >>>>>> _______________________________________________ >>>>>> rules-users mailing list >>>>>> [hidden email] >>>>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>>>> >>>>>> >>>>>> ________________________________ >>>>>> If you reply to this email, your message will be added to the >>>>>> discussion >>>>>> below: >>>>>> http://drools.46999.n3.nabble.com/Multi-Access-to-Stateful-Session-tp3877... >>>>>> To unsubscribe from Multi Access to Stateful Session, click here. >>>>>> NAML >>>>> >>>>> >>>>> -- >>>>> View this message in context: >>>>> http://drools.46999.n3.nabble.com/Multi-Access-to-Stateful-Session-tp3877... >>>>> Sent from the Drools: User forum mailing list archive at Nabble.com. >>>> _______________________________________________ >>>> rules-users mailing list >>>> rules-users@.jboss >>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>> >>> >>> >>> -- >>> View this message in context: >>> http://drools.46999.n3.nabble.com/Multi-Access-to-Stateful-Session-tp3877... >>> Sent from the Drools: User forum mailing list archive at Nabble.com. >>> _______________________________________________ >>> rules-users mailing list >>> rules-users@.jboss >>> https://lists.jboss.org/mailman/listinfo/rules-users >>> >> _______________________________________________ >> rules-users mailing list >> rules-users@.jboss >> https://lists.jboss.org/mailman/listinfo/rules-users >> > > > -- > View this message in context: > http://drools.46999.n3.nabble.com/Multi-Access-to-Stateful-Session-tp3877... > Sent from the Drools: User forum mailing list archive at Nabble.com. > _______________________________________________ > rules-users mailing list > rules-users@.jboss > https://lists.jboss.org/mailman/listinfo/rules-users > _______________________________________________ rules-users mailing list rules-users@.jboss https://lists.jboss.org/mailman/listinfo/rules-users