[rules-users] Multi Access to Stateful Session
gboro54
gboro54 at gmail.com
Tue Apr 3 07:54:47 EDT 2012
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-tp3877599p3880625.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
More information about the rules-users
mailing list