Discussion of
http://jira.jboss.com/jira/browse/JBAS-4608 .
From a support case discussion:
"bstansberry" wrote :
| Will adding FLUSH to a 2.4.1.SP3/4 stack do anything to ensure that a view is received
on all nodes before messages for that view are allowed down the stack?
| "bela" wrote :
| | In most cases, yes. But in 2.4.x, FLUSH didn't have the reconcile code in it,
which meant that we just stopped everyone from sending messages until the new view V2 was
installed. However, we didn't reconcile all messages in V1, meaning that we didn't
ensure that everyone received exactly the same messages in V1. To do that, we added code
in 2.5, which resends missed messages to all members in V1 until V2 is installed.
| |
|
From this it seems adding FLUSH would have some benefit. The
HAPartition and JBC 1.x don't do anything with the block() callback, so it would seem
there'd be no negative side effect of suddenly invoking new code paths in the apps via
block().
A downside is it's a config change, which isn't so good in a point release.
A concern I have about this is the virtual synchrony issues David Ward experienced
apparently weren't there in 4.0.5, which didn't have FLUSH. That implies some
semi-regression occurred. If the regression was a known effect of some design change
where the intent was to counteract it via use of FLUSH, that's OK. But it would be
good to have a clearer understanding of what changed.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4074118#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...