[rules-users] Multi Access to Stateful Session

[gboro54]

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 <gboro54@> 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.