Hey Ales,
I had a quick glance and these are my comments so far:
Do you know where's the javadoc or source for the javax.cache classes?
Also, I'm not sure we can really implement this on top of Infinispan.
Personally I think it's better if it's implemented within Infinispan. For
example:
Well, there's a fundamental difference to how atomic map works to normal cache
operations and that's the fact that the creation of atomic maps is hidden
behind AtomicMapLookup.getAtomicMap. It's not like std cache usage where the
client creates the map that goes into the cache.
So, I don't see
On May 3, 2011, at 2:33 PM, Sanne Grinovero wrote:
2011/5/3 이희승 (Trustin Lee) trus...@gmail.com:
On 05/03/2011 05:08 AM, Sanne Grinovero wrote:
2011/5/2 Manik Surtani ma...@jboss.org:
On 1 May 2011, at 13:38, Pete Muir wrote:
As in, user API? That's a little intrusive... e.g., put(K,
On May 3, 2011, at 8:06 AM, Dan Berindei wrote:
I think Sanne's idea was that you shouldn't have to specify the class
or class loader on every get, as it's very likely that all operations
on that cache will use the same classloader. Most applications will
only use one classloader anyway.
Galder,
I believe the ability to invoke distributed executors and mapreduce over
hotrod would be very interesting. However, I quickly realized that
internals of both DistributedExecutorService and MapReduceTask rely
heavily on some Cache internals (RpcManager, CommandsFactory,
On Wed, May 4, 2011 at 10:14 AM, Galder Zamarreño gal...@redhat.com wrote:
On May 3, 2011, at 2:33 PM, Sanne Grinovero wrote:
2011/5/3 이희승 (Trustin Lee) trus...@gmail.com:
On 05/03/2011 05:08 AM, Sanne Grinovero wrote:
2011/5/2 Manik Surtani ma...@jboss.org:
On 1 May 2011, at 13:38, Pete
On Wed, May 4, 2011 at 7:18 AM, 이희승 (Trustin Lee) trus...@gmail.com wrote:
On 05/03/2011 09:33 PM, Sanne Grinovero wrote:
2011/5/3 이희승 (Trustin Lee) trus...@gmail.com:
On 05/03/2011 05:08 AM, Sanne Grinovero wrote:
2011/5/2 Manik Surtani ma...@jboss.org:
On 1 May 2011, at 13:38, Pete Muir
On 4 May 2011, at 09:55, Dan Berindei wrote:
On Wed, May 4, 2011 at 7:18 AM, 이희승 (Trustin Lee) trus...@gmail.com wrote:
On 05/03/2011 09:33 PM, Sanne Grinovero wrote:
2011/5/3 이희승 (Trustin Lee) trus...@gmail.com:
On 05/03/2011 05:08 AM, Sanne Grinovero wrote:
2011/5/2 Manik Surtani
On 4 May 2011, at 05:34, Dan Berindei wrote:
On Wed, May 4, 2011 at 10:14 AM, Galder Zamarreño gal...@redhat.com wrote:
On May 3, 2011, at 2:33 PM, Sanne Grinovero wrote:
2011/5/3 이희승 (Trustin Lee) trus...@gmail.com:
On 05/03/2011 05:08 AM, Sanne Grinovero wrote:
2011/5/2 Manik Surtani
On Wed, May 4, 2011 at 5:09 PM, Pete Muir pm...@redhat.com wrote:
On 4 May 2011, at 05:34, Dan Berindei wrote:
On Wed, May 4, 2011 at 10:14 AM, Galder Zamarreño gal...@redhat.com wrote:
On May 3, 2011, at 2:33 PM, Sanne Grinovero wrote:
2011/5/3 이희승 (Trustin Lee) trus...@gmail.com:
On
2011/5/4 Pete Muir pm...@redhat.com:
On 4 May 2011, at 09:55, Dan Berindei wrote:
On Wed, May 4, 2011 at 7:18 AM, 이희승 (Trustin Lee) trus...@gmail.com
wrote:
On 05/03/2011 09:33 PM, Sanne Grinovero wrote:
2011/5/3 이희승 (Trustin Lee) trus...@gmail.com:
On 05/03/2011 05:08 AM, Sanne Grinovero
Well, I feel exposing M/R over Hot Rod - from a protocol standpoint - would
require a platform-independent mechanism of defining a closure (keeping in mind
we need to allow this from non-Java clients too).
So I reckon Javascript is the way to go, at least from a protocol standpoint.
Now how
12 matches
Mail list logo
