[rules-users] Multi Access to Stateful Session

Wolfgang Laun wolfgang.laun at gmail.com
Tue Apr 3 02:38:40 EDT 2012


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 <gboro54 at gmail.com> 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 at .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-tp3877599p3877622.html
>>>>>>> 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-tp3877599p3878174.html
>>>>>> 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-tp3877599p3878257.html
>>>>> Sent from the Drools: User forum mailing list archive at Nabble.com.
>>>> _______________________________________________
>>>> rules-users mailing list
>>>> rules-users at .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-tp3877599p3878449.html
>>> Sent from the Drools: User forum mailing list archive at Nabble.com.
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users at .jboss
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at .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-tp3877599p3879423.html
> Sent from the Drools: User forum mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>



More information about the rules-users mailing list