[rules-users] Multi Access to Stateful Session

[gboro54]

I will set up your experiments to to test performance...


gboro54 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 <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-tp3877599p3879424.html
Sent from the Drools: User forum mailing list archive at Nabble.com.