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 <gboro54@> 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]
>>> <ml-node+s46999n3878174h55@.nabble> 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