TOB/TOA integration
by Mircea Markus
Hi guys,
I've just had a chat with the CloudTM team(CC) around the integration of TOB/TOA[1] into Infinispan. Here are some points:
- the TOB and TOA code has been reviewed in detail by us. The only part missing is the state transfer integration
- there's not a lot of sense in integrating TOB/TOM over the existing state transfer as we would not back port that to 5.1 and it would be dropped in 5.2
- CloudTM would rebase the TOB/TOA work on top of the alpha NBST[2](ATM planned at the end of next week/3 Aug) and we'll integrate that
- first releases of the TOB/TOA would be marked as experimental in 5.2
How does that sound?
Cheers,
Mircea
[1] TOA used to be referred to as TOM (M from multicast). In JGroups terminology that's an Anycast, so we decided to be consistent with that and use TOAnycast.
[2] https://community.jboss.org/wiki/Non-blockingStateTransfer
13 years
QueryIterator inconsistencies
by Marko Lukša
Hey
Infinispan's implementations of QueryIterator don't conform to the
contract of ListIterator and are pretty buggy (see
https://issues.jboss.org/browse/ISPN-2337). The most important bug is
the fact that calling next() and then previous() should return the same
element, but it doesn't.
I'm trying to fix the bugs, but have now realized that even the
interface QueryIterator is problematic.
1. QueryIterator.first()
This one isn't as problematic as the next ones, but it's strange that
calling first() and then next() returns the first element of the
collection. It would be clearer if the method were called
"beforeFirst()" or something similar.
2. QueryIterator.last()
What should the iterator return when you call last() and then call
next()? What about if you call last() and then previous()? A user would
probably call last() as the first step of iterating over the results
backwards. So calling previous() should return the last element. The
method should probably be renamed to "afterLast()".
3. QueryIterator.afterFirst() & beforeLast()
These two are OK. Calling next() after afterFirst() should return the
second element, while calling previous() should return the first element.
4. isFirst(), isLast()
ListIterator does not have the concept of "current element", but the
javadoc of all the is*() methods talk about the current element, which
is ambiguous. Therefore isFirst() and isLast() should probably be
renamed to isBeforeFirst() and isAfterLast().
5. jumpToResult(int index)
When jumping to index=1, what does next() return? What about previous()?
We should probably replace the method with two others: beforeResult(int
index) and afterResult(int index)
Any comments / other ideas?
Marko
13 years
x-site: taking a site offline automatically
by Bela Ban
Hi Mircea,
I think we need a 3rd option in addition to a retry interval and a
number of attempts, to take a site offline: a min-time (or whatever we
want to call it).
Say we have retry-interval=1000 and maxRetries=5. This means that if we
get a SITE-UNREACHABLE 5 times for a given site, we declare that site
offline and cease sending requests to it.
However, if we have 5 different threads sending requests to the site,
then each of them will increment the counter and thus we take the site
offline after 1 second !
That's where min-time comes in: we should wait at least min-time until
we take any site offline, even if maxRetries has been exceeded.
Example: min-time=60000 (ms), maxRetries=10, retryInterval=1000 (ms)
If we have 20 threads sending requests to site SFO (which is down), then
we might have numRetries=20 after 10 seconds, and perhaps numRetries=60
after 50 seconds. But only once 60 seconds have elapsed do we take SFO
offline.
The main reason for min-time would be to prevent taking a site offline
during a short period of time when the site master changes and multiple
threads incrementing numRetries in short order.
--
Bela Ban, JGroups lead (http://www.jgroups.org)
13 years
5.2.0.Beta1
by Mircea Markus
Hi,
The planned date for Beta1 is 28th of Sept.
Beta would mean a feature and API freeze - if you think something's critical and won't meet the deadline please let me know.
Following JIRAs must make it in (otherwise we'll hold the release) [1]:
ISPN-2332 - Update xsite configuration file (Mircea, config/api change)
ISPN-2319 - Add ability to take a site offline into x-site implementation (Mircea, required for the xsite functionality)
ISPN-2316 - Distributed deadlock in StateTransferInterceptor (Dan, critical so that QA can progress with testing)
ISPN-1407 - Make sure the server_list attribute of the Hot Rod Client can be updated dynamically (Galder, required by rolling upgrades functionality)
ISPN-1284 - Use synchronizations as a default transactional mode rather than XA (Mircea, small change with big impact on transactions)
[1] same list (updated) is available here: https://issues.jboss.org/secure/IssueNavigator.jspa?mode=hide&requestId=1...
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
13 years
!event.isPre correctness
by Mircea Markus
Hi,
When the listener is notified with (event.isPre == false), the change that triggered the event is not visible to the user[1] as the notification happens before exiting the EntryWrappingInterceptor.
I think this is not right, as a user I'd expect that the post notification to happen after data was applied to the cache, wdyt?
[1] this was raised on the forums: https://community.jboss.org/thread/205515
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
13 years
Re: [infinispan-dev] X-S question
by Mircea Markus
Hi Martin,
Adding infinspan-dev as more people might be interested in this.
On 25 Sep 2012, at 10:13, Martin Gencur wrote:
> Hi Mircea,
> I have a question that was here some time ago but I would like to know the current status: Do you plan to support update operations on remote backups? The last answer in July was that this was out of the scope for the time being.
if cache@siteA and cache@siteB are configured to backup data one into the other, then a user is allowed to write to both sites at the same time.
If the data written is disjunct then there's no possibility for inconsistency disregarding the replication mode.
if there is a chance for concurrent writes on the same data on different sites, then SYNC backup with FAIL replication policy should guarantee that the updates are consistent cluster wise.
>
> I'm asking because we would like to include this into our test plan if possible.
+1.
>
> Thanks
>
> --
> Martin Gencur
> --
> QE Lead, JBoss Data Grid
> Desk phone: +420 532 294 192, ext. 62192
>
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
13 years
Cross-site clustering
by Bela Ban
Hi Mircea,
I'm in the process of setting up the Infinispan GUI demo across 3 data
centers, and I ran into an issue with the Infinispan config file. Not
really a bug, but something that could be improved.
Currently, the Infinispan config (let's call it infinispan.xml) defines
the sites and their backup sites and refers to the local JGroups cluster
config file (jgroups.xml). The latter has a RELAY2 protocol at the top
of its stack which points to the relay configuration (relay2.xml), which
defines the sites and how they connect to each other. Finally, there's a
jgroups-relay2.xml file (referred to from relay2.xml) which defines the
global bridge, connecting all 3 sites.
OK, so that 4 config files and I don't see how to reduce them.
However... currently infinispan.xml is *site-specific*, ie. we need 1
infinispan.xml for LON, 1 for SFO and 1 for NYC.
The 3 JGroups config files (jgroups.xml, relay2.xml and
relay2-bridge.xml) are *not* site-specific, ie. they can be used in any
site, provided that we set a few system properties, such as
cluster-specific mcast address and port, and site name (relay2.xml).
I believe cross-site clustering would benefit from making infinispan.xml
symmetric as well, that is, we could use it in any site.
To do this, I suggest the following:
#1 Sites config:
<sites local="LON">
<site name="SFO"/>
<site name="NYC"/>
<site name="LON"/>
</sites>
Nothing needs to be changed here, except to parameterize local: <sites
local="${SITE:LON}"...>. A node in a given site can then be started
using -DSITE=LON. This could also be used for relay2.xml.
- Question-1: why do we need to list the sites above ? We're not
defining any config for those sites, so I don't see why this is needed...
#2 Backups config:
<namedCache name="users">
<sites>
<backups>
<backup site="NYC" backupFailurePolicy="WARN"
strategy="SYNC" timeout="12000"/>
<backup site="SFO" backupFailurePolicy="IGNORE"
strategy="ASYNC"/>
</backups>
</sites>
</namedCache>
This is *asymmetric*. IMO, a better config would be:
<global>
<sites>
<localSite="${site:LON}" backupSites="${backup-sites:SFO,NYC}" />
<backups>
<backup site="NYC" backupFailurePolicy="WARN"
strategy="SYNC" timeout="12000"/>
<backup site="SFO" backupFailurePolicy="IGNORE"
strategy="ASYNC"/>
<backup site="LON" backupFailurePolicy="IGNORE"
strategy="ASYNC"/>
</backups>
</sites>
</global>
Here, we define global backup strategies and the local site. Both of
them can be parameterized, e.g. we start up nodes in
- LON: -Dsite=LON -DbackupSites="SFO,NYC"
- SFO: -Dsite=SFO -DbackupSites=NYC
- NYC: -Dsite=NYC -DbackupSites= // no backups
This would allow us to have only 1 infinispan.xml, regardless of the
site in which it is used.
Of course, since backup strageties are globally defined, if people
wanted different backup strategies per site (or per named cache), they
could still copy infinispan.xml and modify it...
WDYT ?
--
Bela Ban, JGroups lead (http://www.jgroups.org)
13 years
