[rules-users] Multi Access to Stateful Session
gboro54
gboro54 at gmail.com
Tue Apr 3 10:32:58 EDT 2012
I took part of your solution. Instead of a blocking queue my thread running
the rules session wakes up a time base and calls fireAllRules. Threads up to
that point are allowed to insert any data they want. This seems to prevent
any weird sync logic. I will continue testing this approach
gboro54 wrote
>
> Thanks for the information. I do plan to run the test cases as I am
> curious about this issue. It is important to note that the sync issue does
> not arise if I just pass every message in and let the rule session work
> out the messages based on previous information(however the messages have
> no sync methods). This is the reason I proposed just creating immutable
> dereg facts and passing them along and allowing each session to maintain
> its own place holder. My only concern with the queue is that messages just
> continue to pour in and the session can't call fireAllRules until every
> message in session is available.
>
>
> laune wrote
>>
>> 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@> 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 <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 at .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-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 .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-tp3877599p3881143.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
More information about the rules-users
mailing list