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

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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users