Distributed Streams
by William Burns
Hello everyone,
I wanted to let you know I wrote up a design documenting the successor to
EntryRetriever, Distributed Streams [1] !
Any comments or feedback would be much appreciated.
I especially would like targeted feedback regarding:
1. The operators forEach and peek may want to be ran locally. Should we
have an overridden method so users can pick which they want? Personally I
feel that peek is too specific to matter and forEach can always be done by
the caller locally if desired.
2. The intermediate operators limit and skip do not seem worth implementing
unless we have sorting support. (Sorting support will come later). I am
thinking to not support these until sorting is added.
Thanks,
- Will
[1] https://github.com/infinispan/infinispan/wiki/Distributed-Stream-Support
10 years, 11 months
Interceptor stack for local caches
by Radim Vansa
Hi,
few weeks ago I was looking into performance of local cache when
compared to basic concurrent hash map, or data container. I can't find
the exact results now, but the difference was in order of magnitude -
IIRC concurrent hash map was about 20x faster than local cache. There
was no 'bottleneck', but the versatile Infinispan design of commands
traversing through interceptor stack brings some overhead (e.g.
allocation costs with each invocation, not only for writes) while in
some use cases it is not necessary to keep this complexity. The use case
I am looking for is caching in Hibernate ORM, which basically requires
only map with eviction, expiration and transactions in some cases. No
need for cache stores, statistics etc. So far I've found ways to remove
few interceptors [1], but it's few percent, not hundreds of percent
where I would ideally aim.
Therefore, I was considering about an option to inspect cache
configuration and in suitable cases return LocalCacheImpl that would get
rid of the burden: no interceptor stack, no commands instantiation. This
would be transparent to the user. I understand that it will increase
maintenance costs, but it still seems better to me to have it under
wings of Infinispan as caching solution rather than separate project, as
it can share a lot of the codebase.
Do you think that this idea makes sense, or is it just too wild? Do you
think I will crash when trying to implement this?
Radim
[1] https://issues.jboss.org/browse/ISPN-5542
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
11 years
Infinispan 7.2.3.Final
by Tristan Tarrant
Dear Infinispan users,
thanks to your help, a few bugs have been found and fixed in the
Infinispan 7.2 branch. So if you are affected by any of the bugs below,
now is the time to upgrade.
Bug
[ISPN-4123] - Remote Query tests random failures
[ISPN-5444] - Filter/converters in server can't unmarshall custom
cached classes
[ISPN-5522] - LIRS BoundedConcurrentHashMapv8 eviction for tree bin
missing check
[ISPN-5524] - Race condition in
SemaphoreCompletionService.executeFront()
[ISPN-5527] - Java system properties no longer supported in leveldb
expiration path
[ISPN-5531] - java.lang.UnsupportedOperationException during remove
(using RemoteCacheManager)
[ISPN-5543] - Bad tracef arguments are causing
IllegalFormatConversionException
[ISPN-5560] - NotSerializableException for invalidation-cache
[ISPN-5565] - Memory leak in Hot Rod client tests
[ISPN-5566] - Listener Observation is not obeyed for non
CacheEntryEvents
Enhancement
[ISPN-5519] - Cannot choose to run index-less query on an indexed
cache in compat mode
Again, downloads and release notes are at the usual pages, so go and
check them out !
Happy hacking.
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
11 years
Cache Java 8 API proposal - 2nd draft
by Galder Zamarreño
Hi all,
Thanks to all who contributed to the 1st draft revision. We've taken all that input and created a separate Github project where we have prototytped the 2nd draft of the advanced Java 8 based Infinispan API. The starting point for you should be FunctionalMap [1].
Here's a brief summary the major changes since the 1st draft:
1. FunctionalMap has been separated into 3 sub-interfaces, one for read only operations, one for write only operations, and a final one for read-write operations. This separation makes it clear the purpouse of each operation and adds a nice layer of type safety, e.g. you can't write with a read-only map, or you can't read with a write-only map.
2. Param has been added, which is equivalent to Infinispan Flag with the added benefit that it can carry values. There's no such example right now but we could have in the future.
3. MetaParam has been added. This is a much more flexible and extensible option compared to the current Infinispan's Metadata.
4. For operations returning mutiple returns, or working on multiple elements, we've exposed something called Traversable, which is a subset of Java's Stream. See its javadoc to find out more. Kudos to Will for his work on distributed streams which has helped hugely with the design of Traversable.
5. Listeners have been added, again separating between read-write and write-only listeners (JCache does not offer read-only listeners, e.g. cache entry visited, and hence I think we'll drop our cache entry visited listener at some point).
6. Will and I have explored marshalling aspects of lambdas, and there are some interesting ways to reduce their costs by +90%! See MarshallingTest for different options to marshall both capturing and non-capturing lambdas and their cost in terms of payload sizes.
Some final notes:
* Please do read the javadocs, they contain a lot of information on the reasons behind the design.
* To find out how the different functional map variants are used, look at ConcurrentMapDecorator and JCacheDecorator who use them to implement the ConcurrentMap and javax.cache.Cache APIs respectively.
* FunctionalMapTest contains examples on how to use functional map variants for other operations which we deeply care about, e.g. Hot Rod atomic version-based replace function.
Special thanks to Mario Fusco (Java 8 In Action book co-author) for his feedback throughout this 2nd draft design process.
Cheers,
[1] https://github.com/infinispan/proto8/blob/master/src/main/java/org/infini...
--
Galder Zamarreño
galder(a)redhat.com
11 years
C++/C# clients bumping to C++11 and .NET 4.5
by Tristan Tarrant
Hi all,
In the past we've based our C++ code around C++03 so that it would be
usable on RHEL5. This however precludes us from using many of the
interesting features introduced in C++11 (proper auto_ptr, atomic, etc).
I think we should branch the current native clients for 7.x so that
master can be updated to more recent compilers:
- G++ 4.7 as a minimum
- MSVC 2012 and .NET 4.5
Comments ?
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
11 years
State Transfer & Invalidation Caches
by William Burns
Recently [1] was found. The underlying cause is that now initial state
transfer is enabled by default including invalidation caches.
When thinking about this I didn't even realize that we utilize a Replicated
consistent hash for invalidation mode. This all strikes me as just wrong.
To me an invalidation cache is just a local cache that sends broadcasted
invalidation messages to other members. It shouldn't have any need for a
consistent hash.
Currently though we have an invalidation cache that will try to acquire
remote locks [2], reports ownership of keys by the consistent hash (instead
of each node owning every key as it would be in a local cache [3]), which
will participate in initial state transfer (REPL based) [4] among other
things. We even have invalidation commands that are tied to given
topologies [5].
I was originally planning on cutting the cord between invalidation caches
and state transfer, but I am finding so many places that assume we have a
topology that it requires more code that I would have thought. So I wanted
to check if anyone had any objections. If there are objections I can end
up taking the quick and easy route of just forcing disabling of initial
state transfer and leaving everything as it is otherwise. I personally
feel we should completely separate these concepts to guarantee what I would
think as proper behavior.
Thanks,
- Will
[1] https://issues.jboss.org/browse/ISPN-5560
[2]
https://github.com/infinispan/infinispan/blob/master/core/src/test/java/o...
[3]
https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o...
[4]
https://github.com/infinispan/infinispan/blob/master/core/src/test/java/o...
[5] https://issues.jboss.org/browse/ISPN-4016
11 years
Threads, Quasar, Fibers and DSLs
by Sanne Grinovero
Hi all,
we recently discussed about the problem of modelling locks as Java
locks, and blocking our actual threads - or have to delegate to
internal large threadpools - to model the "parking" of a thread which
is visiting the interceptor chain, when all we want is to model a lock
as a boolean with possibly some metadata like owners and timestamps.
We all agreed that it needs to change, and we proposed some high-level
basic ideas about how to store the "on stack" state in some container
object. We know what we want to achieve, but I haven't seen yet much
progress on details about how exactly get there.
One basic first step we discussed is to split the internal contract of
the visitor chain between separate methods "up" and "down" (very much
in JGroups style). That would force us to highlight local variables,
which need to be moved within an appropriate container.
We then briefly discussed how such a container should model a stack,
to allow for different visitors to avoid name clashing, and do it
efficiently: we wouldn't like to allocate a vector for the stack, nor
use a dictionary for the names-object variables, but at every least a
custom payload object would need to be coded for each visitor, and
appended to the chain.. that would have the allocation costs of a
linked list and a container object to allow field access pointers be
allocated for each visitor in the chain.
Pooling is also an option.. but really it's all just looking horrible :-)
I was now reading about Quasar and Fibers (credit to Mark Little and
Tim Fox for the pointer) :
- http://docs.paralleluniverse.co/quasar/
It seems very interesting, and relevant to our Infinispan discussion.
Although it does much more than what we need and the prospect of
supporting production systems which extensively rely on ASM and modify
definitions like threads and lock owners scares me a bit, so I'm not
advocating we use Fibers directly but it would be very nice to:
- be able to experiment with it
- see if something similar could be done without needing the bytecode
manipulation
- maybe use it?
The overall impression I get, is that it's a very complex task for us
to split the visitor chain at this point, and it's equally expensive
to make any such experiment viable, so embarking in an experiment to
evaluate something like Fiber gets the "Epic" JIRA level.. but there
might be better ways!
If you look at our RPC Commands, a lot of code is very repetitive,
following established patterns and conventions. The component of the
Visitor chain are a bit less repetitive, but still there are some
patterns.
So, what if we had some basic templates for all this repeating code,
and used a custom DSL to define what a Command or a Visitor is
supposed to do?
I'm not suggesting we invent yet another general purpose programming
language, but something very ad-hoc which takes the input we need and
generates Java sources which we all understand, so issues in the code
generation should be easy to spot (better so than ASM!).
If we had such a tool, it would be sustainable to make cross-the-board
changes to the threading model, experiment with things like Fibers,
generate the visitor code and the correct stack handling w/o getting
dirty with very boring code which we don't even know how it will work
out.
In addition such a tool could optionally be enhanced to generate
metadata for tooling, like correctness evaluations, model checkers,
inject correct trace logging w/o polluting our design, output to
visualizers or other debugging helpers.
More importantly, it would significantly reduce the manpower needed to
experiment with model changes which would otherwise affect a too large
code base. For example, for some configurations one might not need the
InvocationContext at all, and to push the performance level to the
extreme it would be better handled by generating an alternative set of
visitors (or use bytecode manipulation).
Thanks,
Sanne
11 years
How to make Snapshot of whole data saved in infinispan ?
by 杜天微
I put all my data in infinispan , within some servers.
Some time , I hope I could take a snapshot of data in infinispan ,
so that I could roll back to any point of time I made the snapshot.
Could any one tell me how to make it come true ?
Thanks for reading my poor english .
11 years
