Infinispan project versioning
by Mircea Markus
Hi,
There has been some confusion (me included) on how release versioning works in Infinispan.
We follow the "standard" versioning scheme as described in the JBoss Project Versioning document[1] with the following meaning for release versions:
- Alpha - early releases that are not API complete, but have usuable new functional capabilities the community can benefit from
- Beta - releases where the release is API complete, but its not completely tested, or there may even be questions about the API itself, that may change, even though the implementation is complete
- CR - ready to be released from our POV, just waiting for community's validation
- Final...
[1] https://community.jboss.org/wiki/JBossProjectVersioning
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
10 years, 11 months
Recovery with async cache mode
by Pedro Ruivo
Hi,
(related to ISPN-3063)
I noticed while working on ISPN-3063 that we allow Recovery even if the
CacheMode is async.
My opinion, this does not makes sense because we send the prepare as 1
phase commit. So it is impossible to have in-doubt transaction to be
recovery later (right?)
The strange part, when I add this condition to the
RecoveryConfigurationBuilder.validate(), hundred of tests are running in
this configuration (async cache mode + recovery). However, this
combination should not be possible by [1]. Note that the test is
currently disable but I'm fixing it and I want to enable it in ISPN-3063.
Question: change the test suite or remove the test [1]?
I think the correct thing to do is to fix the test suite and throw an
exception if someone tries to enable recovery with async cache mode.
wdyt?
Cheers,
Pedro
[1]
https://github.com/infinispan/infinispan/blob/master/core/src/test/java/o...
10 years, 11 months
5.3.0 release schedule
by Mircea Markus
Hi,
ATM the schedule for 5.3.0 looks like this:
18th May Beta2
The big things for this Beta are:
- finish ISPN-2281 - Enable inter server endpoint communication in a compatibility mode (Galder)
- ISPN-2772 - Implement REPLICATED mode as a degenerated DISTRIBUTED mode (nowOwners>=clusterSize) (Adrian)
25th May CR1
7th June Final
Post 18 May we should slow down development and move back to bug fixes as we still have a bunch of critical issues to address.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
10 years, 11 months
moving (some) cache stores in a different github repository
by Mircea Markus
Hi,
Because of the hight number of dependencies and large distribution size (build time as well) there were discussions about moving some of the cache stores into an independent git repository under the infinispan project. Now that we have two more cache stores to be integrated (JPA and MongoDB), it's a good opportunity to start a discussion around this.
The cache stores I'm thinking about are: JPA, MongoDB (integrated them directly in the new repository), Cassandra, Cloud, HBase, jdbm and bdbje. Or thinking more about it, why not all of them but the file cache store - which is dependency free and it's nice to ship it .
There are several options when it comes to releasing these stores. I think the simplest is by to a maven repo (i.e. no .zip file). If there'll be demand for specific distribution files we can always add it at a further point in time.
wdyt?
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
10 years, 11 months
distributed fork-join executor prototype
by matt hoffman
Hey guys,
I've been working on a prototype of integrating Infinispan into our app.
We do a lot of distributed processing across a small cluster, so I've
played with Infinispan's existing distributed execution framework (which is
nice), as well as using Infinispan alongside a normal message queue to
distribute tasks. But I've also put together a prototype of a new
distributed execution framework using fork-join pools that you all might be
interested in. If it sounds like something that would be worthwhile for
Infinispan, I can raise a Jira and submit a pull request with what I have
so far. I'd need to get the CA and company policy stuff finalized; that
might take a couple days. Meanwhile, in case there is any interest, I've
described the approach I've taken below.
First, a little background:
A while back I worked on a side project that integrated a distributed
work-stealing algorithm into the standard JDK fork-join queue. It used
JGroups for communication, because it was quick and easy for prototyping.
So this week I thought i'd take a stab at porting that over to Infinispan.
The algorithm I came up with for Infinispan is a bit less of a
work-stealing algorithm, to take advantage of Infinispan's built-in
distribution capabilities, but I think it's still fairly efficient.
My basic approach was to take in a cache in the constructor, much like the
existing distributed executor, and then create a parallel, DIST-mode cache
that uses the same hash & grouping configuration as the original cache.
That new parallel cache is the "task cache", and we use that to distribute
available tasks across the cluster. It's a distributed cache so that tasks
are partitioned across a large cluster, and it uses the hashing config of
the original cache and a KeyAffinityService to attempt to distribute the
tasks to the same nodes that contain the data being worked on. Nodes use
cache listeners to be notified when there is new work available, and the
atomic replace() to "check out" the tasks for execution, and "check in" the
results.
The basic algorithm is something like this:
For a refresher, a normal FJ pool has a fork() method that takes in a task,
and then places that task on an internal queue (actually, one of several
queues). When threads are idle, they look to the nearest work queue for
work. If that work queue does not have work, they "steal" work from another
thread's queue. So in the best case, tasks remain on the same thread as
the task that spawned them, so tasks that process the same data as their
parents may still have that data in the CPU's cache, etc. There's more to
it than that, but that's the basic idea.
This distributed algorithm just adds an extra layer on top for tasks that
are marked "distributable" (by extending DistributedFJTask instead of the
normal ForkJoinTask). When you call fork() with a DistributedFJTask, it
first checks to see if the local pool's work queue is empty. If so, we just
go ahead and submit it locally; there's no reason to distribute it. If not,
we put the task in the task cache, and let Infinispan distribute it. When a
node has no more work to do in its internal fork-join queues, it looks at
the task cache and tries to pull work from there.
So, it isn't really a "work-stealing" algorithm, per se; the distributable
tasks are being distributed eagerly using Infinispan's normal cache
distribution. But I'm hoping that doing that also makes it easier to handle
node failure, since nodes collectively share a common picture of the work
to be done.
This approach required one change to the actual FJ classes themselves
(in org.infinispan.util.concurrent.jdk8backported).
That's probably the most controversial change. I had to make the original
ForkJoinTask's fork() method non-final in order to extend it cleanly.
There's probably a way around that, but that's the cleanest option I have
thought of thus far.
And lastly, it's not done yet: basic task distribution is working, but I
haven't tackled failover to any real extent yet. The biggest questions,
though, are around what to do with the existing distributed execution
interfaces. For example, DistributedTask has a getCallable() method because
it assumes it's wrapping a Callable. But ForkJoinTasks don't extend
Callable. I could put in a shim to wrap the DistributedFJTasks into
Callables for the sake of that method, but I don't know if it's worth it.
Similarly, the DistributedExecutorService interface exposes a lot of
submit-to-specific-address or submit-to-all-addresses methods, which are an
odd fit here since tasks are distributed via their own cache. Even if I
used a KeyAffinityService to target the task to the given Address, it might
get picked up by another node that shares that same hash. But I can add in
a direct-to-single-Address capability in if that seems worthwhile.
Alternately, I can just use entirely different interfaces
(DistributedFJExecutorService, DistributedFJTask?).
Thoughts? Concerns? Glaring issues?
10 years, 12 months
Splitting the Lucene Directory in its own top-level project
by Sanne Grinovero
Following on the idea about CacheStores, I'd like to propose having
the Lucene Directory code to live in its own repository with an
independent release cycle.
Tests-wise it should follow the same policy of the CacheStore: adding
enough tests to the core so that it won't break easily, and in worst
case have the core team jump in to help.
But in this case there is a strong benefit: having the Lucene
Directory to release independently would make it easier to roll out
updates needed by consuming projects which are pinned to the
Infinispan (core) version included in the application server. Most
notably this would break the "circular release dependency" between
Search and Infinispan, and allow quicker innovation in Hibernate
Search while staying compatible with the application server.
Sanne
10 years, 12 months
[Discussion] TimeService implementation
by Pedro Ruivo
Hi,
The TimeService interface is going to replace all the System.nanoTime()
and System.currentTimeMillis() in the code and it will allow to replace
in the test suite in order to provide a better control over the time
dependent code (if needed).
The objective of this email is to discuss possible implementation and
interface that will cover the needs of everybody (or at least try it).
Later I'll create a JIRA and start the implementation (except if someone
really wants to implement it :P)
* Interface:
//return the current time in nanoseconds and milliseconds respectively
long nowNanos()
long nowMillis()
//return the duration between now() and the startNanos/Millis
long durationNanos(long startNanos)
long durationMillis(long startMillis)
//return the duration between start+ and end+
long durationNanos(long startNanos, long endNanos)
long durationMillis(long startMillis, long endMillis)
Any other method? Maybe adding a TimeUnit parameter instead of duplicate
methods (e.g. now(TimeUnit))? Maybe some convert() with double
precision, since the TimeUnit.convert(...) usually loses precision?
(I need double precision for the Extended Statistics, but I can put this
converters in my classes)
* Scope:
Should the TimeService be in a cache or global scope? My vote is per
cache...
* Configuration
Should we provide a configuration to pass an implementation of the
TimeService interface? if yes, we may need to change the methods above
to return some interface (e.g. TimeStamp) in order to support almost
anything.
Any other subject? Thoughts?
If I was not clear let me know...
Cheers,
Pedro Ruivo
10 years, 12 months
Re: [infinispan-dev] [infinispan-internal] Message flow tracer/analyzer
by Radim Vansa
----- Original Message -----
| From: "Galder Zamarreño" <galder(a)redhat.com>
| To: "Radim Vansa" <rvansa(a)redhat.com>
| Cc: "infinispan-internal Internal" <infinispan-internal(a)redhat.com>
| Sent: Thursday, May 2, 2013 7:49:53 PM
| Subject: Re: [infinispan-internal] Message flow tracer/analyzer
|
| Did you look into Twitter's Zipkin? It looks very suited for doing this kind
| of stuff:
| http://engineering.twitter.com/2012/06/distributed-systems-tracing-with-z...
|
| It could be used in combination with Byteman and it gets you a nice user web
| interface :)
Thanks for pointing me to that, Galder, I should probably read more blogs :)
This looks very similar and integrating with the nice GUI could be cool, but I am not sure whether it's worth the effort (read: I probably won't have time for this).
The main difference is that with Byteman I don't have to modify the code to pass the zipkin header along with the request. Not relying on Byteman would be cool (I don't believe that the few accesses of ConcurrentHashMap and ThreadLocal variables slow the system 3 times, Byteman must introduce a lot of its own overhead). Eventually I may end up with interpreting the rules on JGroups/ISPN source level and inserting the calls directly into the source code. I know Byteman can do that on the bytecode level but there are some bugs that prohibit from doing so (and Andrew Dinn noted that these may end up being "won't fix" as fixing them may break other stuff).
Nevertheless, I will probably rename data -> annotation, control flow -> span, message flow -> trace in order to be consistent with Zipkin naming.
|
| p.s. It's written in Scala.
Oh, <irony>great!</irony> ;-)
Radim
|
| On May 2, 2013, at 2:48 PM, Radim Vansa <rvansa(a)redhat.com> wrote:
|
| > Good news, everyone,
| >
| > in the last two weeks I've been working on a tool that could help us to
| > profile Infinispan performance, analyze it and probably debug some stuff
| > as well. While trace logs are the most useful, performance is impacted to
| > almost unusable levels and it still does not provide enough information,
| > logs have low precision etc.
| > The idea is to analyze the behaviour based on the requests and track down
| > the consequences of each request (put/get/whatever). Currently I have a
| > working prototype (I believe already useful) which is able to track down
| > all messages based on the initial request, records which threads execute
| > etc. It's Byteman based, no trace logs/code changes required. However,
| > according to my initial testing it reduces the overall performance 2-3
| > times.
| >
| > The code is located in https://github.com/rvansa/message-flow-tracer ,
| > please look at README for details what it can do and ping me if you have
| > any questions/feedback.
| >
| > Radim
| >
| > PS: short demo output on http://pastebin.com/raw.php?i=SBQFuG3a
| >
| > -----------------------------------------------------------
| > Radim Vansa
| > Quality Assurance Engineer
| > JBoss Datagrid
| > tel. +420532294559 ext. 62559
| >
| > Red Hat Czech, s.r.o.
| > Brno, Purkyňova 99/71, PSČ 612 45
| > Czech Republic
| >
| >
|
|
| --
| Galder Zamarreño
| galder(a)redhat.com
| twitter.com/galderz
|
| Project Lead, Escalante
| http://escalante.io
|
| Engineer, Infinispan
| http://infinispan.org
|
|
10 years, 12 months
KeyAffinityService, GroupingConsistentHash et. al. Infinispan tactical APIs
by cotton-ben
Hi Infinispan-DEV team,
Could anyone provide pointers to Infinispan API sample code that could
assist us w/ our ambition to start building the attached distributed grid
use-case?
Any wiki "how-to" (or full code samples) would be especially helpful.
Specifically, how to use
KeyAffinityService,
GroupingConsistentHash,
JGroupsTopologyAwareAddress,
etc.
would be ideal.
Thanks,Ben
/
by Ben.Cotton(a)jpmorgan.com May 8, 2013 9:45 AM
Ambition = on an Infinispan 5.3 grid of 4 nodes (4 x JVM, all nodes have
same IP address, each node has a different socket port)
I. distribute/partition a <K,V> set (call it set-A) uniformly across the
grid and
II. pin a separate <K,V> set (call it set-B) at exactly 1 node on the grid.
How do I best do this in 5.3?
Questions:
JGroupsTopologyAwareAddress - is it configurable to include at least
"ip_address+port"? what is the physical anatomy of a
jGroupsTopologyAwareAddress?
GroupingConsistentHash - this looks like a good starting basis for achieving
our ambition. Are there code samples that demonstrate how to use this?
KeyAffinityService - is this API intended to insulate the User from having
to worry about JGroups specific details? i.e If I use the
KeyAffinityService, can I get away without having to know how to code via
JGroupsTopologyAwareAddress a/o GroupingConsistentHash?
Once we get our ambition realized in a running Infinispan 5.3 grid instance
of 4 nodes:
Assume that node #1 has set-B pinned to it (exclusively). Is there any way
that nodes #2,#3,#4 can then operate on set-B *by reference* (sort of like
RMI operations over a network-stub to the operand implementation), or is it
necessary that nodes #2,#3,#4 must consume *by value* a copy of set-B into
its' JVM address space before they can operate on set-B?
Thanks for any helpful insights, tactics and code samples.
Thanks,
Ben
/
*by Bela Ban on May 8, 2013 12:07 PM
I'll try to address this in generic terms, for details (e.g. which classes
to use etc) contact the Infinispan team.
To distribute set A (more or less) evenly across a cluster, use mode=DIST.
To ping set B to a single node, also use DIST, but set numOwners=1 and plug
in your own consistent hashing function which pins all keys to a given node.
E.g. if you have view {M,N,O,P}, the consistent hash could pin all keys to
the first member of the list, M. This works because every member in a
cluster has the same view (unless there's a split).
However, this *will* lead to uneven distribution, so if set B is large, node
M will bear more of the work than other nodes.
Also, numOwners=1 is usually only advisable if you can fetch the data from
somewhere, e.g. a DB, and use the cluster only as a front-end cache to a DB,
for example.
You could fix this by setting numOwners=2, and coming up with a consistent
hash function which always pins the first of the 2 return values, e.g.
[M->N], [M->O], [M->P], [M->N] etc.
Once key set B is pinned to M, all access (using DIST) on other nodes will
be routed to M. Note that you *could* use an L1 cache, which caches locally,
but you stated you don't want to do that.*
--
View this message in context: http://infinispan-developer-list.980875.n3.nabble.com/KeyAffinityService-...
Sent from the Infinispan Developer List mailing list archive at Nabble.com.
10 years, 12 months
