7:51 a.m.
I have a stateful session which is having objects inserted and updated from
multiple threads. The thread managing the session is using the fireUntilHalt
method as below:
@Override
public void run() {
if (logger.isDebugEnabled()) {
logger.debug("Starting session...");
}
threadName = Thread.currentThread().getName();
session.fireUntilHalt();
}
The code being invoked to insert/modify objects is below:
public synchronized void insertOrUpdate(Object fact) {
Preconditions.checkNotNull(fact);
FactHandle factHandle = session.getFactHandle(fact);
if (factHandle == null) {
session.insert(fact);
} else {
session.update(factHandle, fact);
}
}
The problem I am running into is that I have a control fact which keeps an
internal counter(messages coming in are sequenced and need to be processed
in order) and a list of "deregister messages"(messages that are not going
to be inserted for various reasons). The problem I am having is that 75% of
the time it seems something goes wrong with the counter and messages stop
being processed and build up in the session. If i pass every message in and
don't try and deregister any everything works ok. The rules I have for
working with the message deregister is as follows(this is a an example there
are will be other rules added eventually):
rule "Dereg Message"
salience 10000
when
$controller:MessageControl($pos:currentPosition,excludedPositions[$pos]!=null)
then
modify( $controller ){
moveCurrentPositionForward(1)
}
end
rule "Remove Message"
salience -15000
when
$controller:MessageControl($pos:currentPosition,excludedPositions[$pos]==null)
$tsc:Message(rank==$pos)
then
cdiEvent.fire(new CDIEvent($tsc));
retract($tsc);
modify( $controller ){
moveCurrentPositionForward(1)
}
end
The controller class is:
private BigInteger currentPosition = new BigInteger("0");
private Map<BigInteger, BigInteger> excludedPositions = new
ConcurrentHashMap<BigInteger, BigInteger>();
public synchronized void addPositionToExclusionList(BigInteger position) {
excludedPositions.put(position, position);
}
public synchronized BigInteger getCurrentPosition() {
return currentPosition;
}
public synchronized void moveCurrentPositionForward(Integer value) {
currentPosition = currentPosition.add(new BigInteger(value.toString()));
}
public synchronized Map<BigInteger, BigInteger> getExcludedPositions() {
return excludedPositions;
}
public synchronized Collection<BigInteger> getExclusionList() {
return excludedPositions.values();
}
Any thoughts to why this may be occuring? I have been banging my head on
this problem for a couple days. We are using drools 5.3
--
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.
8 a.m.
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.
11:18 a.m.
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 <gboro54(a)gmail.com> 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
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
11:49 a.m.
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(a)n3.nabble.com> 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.
12:35 p.m.
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(a)gmail.com> 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(a)n3.nabble.com> 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.
12:45 p.m.
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.
1:12 p.m.
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(a)gmail.com> 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
6:14 p.m.
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
--
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.
6:14 p.m.
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 <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
>
--
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.
1:38 a.m.
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(a)gmail.com> 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@.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
>
--
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
6:54 a.m.
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@.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
>>
>
>
> --
> 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
--
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.
9:32 a.m.
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@.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
>>>
>>
>>
>> --
>> 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
>
--
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.
4620
days inactive
4621
days old
11 comments
2 participants
participants (2)
-
gboro54 -
Wolfgang Laun