Fwd: [concurrency-interest] ConcurrentHashMapV8 now supports Spliterator
by Galder Zamarreño
@Vladimir, something of potential interest for your distributed executors stuff in the future? Also check the compute/computeIfAbsent operations coming up in new CHM.
Begin forwarded message:
> From: Doug Lea <dl(a)cs.oswego.edu>
> Subject: [concurrency-interest] ConcurrentHashMapV8 now supports Spliterator
> Date: July 4, 2012 1:47:51 AM GMT+02:00
> To: "Concurrency-interest(a)cs.oswego.edu" <Concurrency-interest(a)cs.oswego.edu>
>
>
> In addition to including the compute/computeIfAbsent changes
> discussed on this list last week, the updated version of
> ConcurrentHashMapV8 contains basic support for performing
> parallel (normally via ForkJoin) operations on the keys,
> values, or entries of a map.
>
> The added Spliterator interface (see
> http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166edocs/jsr166e/ConcurrentHas...)
> is for now a nested interface that contains a subset of
> some functionality likely to be available in JDK8.
> There are also three new methods to provide them:
> public Spliterator<K> keySpliterator()
> public Spliterator<V> valueSpliterator()
> public Spliterator<Map.Entry<K,V>> entrySpliterator()
> See the Spliterator javadocs for a usage example.
>
> These methods only provide a foothold for writing your
> own parallel operations. CHMV8 doesn't now itself supply
> the map, filter, reduce, forEach, etc operations expected
> to be supported under JDK8 lambda-ized collections. However,
> they do enable those familiar with ForkJoin programming
> to get a head start evaluating such code you write yourself.
> If you do this, please report back any interesting experiences.
>
> The usual links:
> * API specs: http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166edocs/
> * jar file: http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166e.jar (compiled using Java7 javac).
> * Browsable CVS sources: http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166e/
>
> -Doug
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest(a)cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
13 years, 10 months
Github secrets
by Galder Zamarreño
See: https://vimeo.com/42530011 (posted on hibernate-dev)
Amongst interesting stuff:
- to see a patch without whitespace changes: add ?w=1 to url
- press "t" on a GitHub repo page for the file finder which allows to quickly open files
Also very interesting, doing pull requests of branches, around minute 23. The interesting part is that you could avoid the need of forks…
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
13 years, 10 months
IRC meeting log
by Galder Zamarreño
Meeting bot was not working (??), so find attached the log.
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
13 years, 10 months
new module: integration tests
by Sanne Grinovero
In projects like Hibernate Search and OGM we added a new module
"integrationtests" where we can add specific tests needing non-core
dependencies, like booting the framework on AS7 via Arquillian or
using a custom TransactionManager.
I need now to make a test which requires both Infinispan Query and the
Infinispan Lucene Directory. If I add the dependency of one to the
other - even just as test scope - I'll be binding the dependent
version to each other which brings me in a circular dependency problem
with Hibernate Search (a bit because of how Maven works, a bit of how
Eclipse works...).
So are you all fine if I create a new module
/integrationtests/clusteredquerytests
?
We can then add more integration tests as siblings.
Cheers,
Sanne
13 years, 10 months
Dynamic data placement
by Pedro Ruivo
Hi all,
In the Cloud-TM project we are working on a technique to change
dynamically the distribution of data across the nodes of an ISPN data
grid. The idea is basically to determine at run-time which are the keys
most accessed by each member/node and move these keys to that nodes. The
ultimate goal is to maximize data locality and reduce the number of
remote get operation.
One of the ingredients of the solution is to define a mechanism that
allows the entire data grid, which is running in a configuration A,
having a given data distribution strategy (determined by the current
hash function implementation), to switch to a configuration B, in which
all nodes have agreed on a new data distribution strategy, and have
completed to relocate accordingly the keys.
Our idea therefore is to add a functionality in ISPN, which allows to
support the dynamic change of the data distribution criterion (namely
the consistent hash function).
To us this mechanism resembles closely the state transfer problem,
except that in the latter case the keys are relocated when a node joins
or leaves the system.
We were thinking to implement this by introducing a command (say,
RedistributedDataCommand) that would take as input a new hash function,
and that would internally trigger a state transfer based on the hash
function passed as input parameter. Another alternative would be to
change the CacheViewControlCommand, allowing it to distributed across
all the nodes the new hash function, as well as to trigger the state
transfer.
The point is that we would like to do this in a clean way, in order to
simplify a possible future integration. We will therefore be grateful
for any feedback that you will be able to provide.
Cheers,
Pedro Ruivo
13 years, 10 months
