Sanne's correct. If you are interested, then make a comment on the pull req
first on github.
On 15 Apr 2011, at 16:55, Sanne Grinovero wrote:
> that would generate a lot of emails, I'd have to start filtering out
> this list :/
> We are supposed to have at least one person to review each patch
On 15 Apr 2011, at 17:43, Olaf Bergner wrote:
>>>
>>> Plus, I fear rehashing would have to be aware of wheter it is dealing with
>>> relocating a large object chunk or a "regular" value.
> See above: if a node leaves the cluster rehashing might relocate large
> object's A 's chunk to a node th
Do we also want to give end-users the option of pre-registering externalizers
so that they can take advantage of (even) smaller payloads using a short
identifier for externalizer ID?
On 29 Mar 2011, at 08:24, Galder Zamarreño wrote:
>
> On Mar 28, 2011, at 3:50 PM, David M. Lloyd wrote:
>
>>
How do you generate the Long internalID of an XID?
Another approach may be to take the byte[] (XID) and Base64 it. Then you have
a 1-to-1 mapping between the XID and a JMX-friendly String. :-) Or maybe an
SHA1 hash of the byte[].
On 4 Apr 2011, at 12:46, Mircea Markus wrote:
> Hi,
>
>
On 15 Apr 2011, at 18:15, Olaf Bergner wrote:
> Actually, it might make sense to split Spring Infinispan into two modules.
> One containing the Infinispan backed Spring Cache SPI implementation proper,
> and another one containing all those additional support classes for working
> with "native
On 15 Apr 2011, at 17:53, Olaf Bergner wrote:
> Am 15.04.11 17:01, schrieb Manik Surtani:
>> On 10 Apr 2011, at 21:07, Olaf Bergner wrote:
>>
>>> Keep in mind that so far I have completely ignored the issue of
>>> supporting transactions when reading and writing large objects. I would
>>> prefer
On 15 Apr 2011, at 17:56, Olaf Bergner wrote:
> Am 15.04.11 16:59, schrieb Manik Surtani:
>> On 13 Apr 2011, at 19:26, Mircea Markus wrote:
>>
>>> IMO the large object methods would fit better in the Cache directly, vs
>>> AdvancedCache.
>> Perhaps a new interface? StreamingCache?
> I do like
On Apr 15, 2011, at 3:23 PM, Vladimir Blagojevic wrote:
> On 11-04-15 4:34 AM, Galder Zamarreño wrote:
>> On Apr 12, 2011, at 7:45 PM, Vladimir Blagojevic wrote:
>>
>>> Yeah, it would be too strict to require Callable to be Cloneable so I
>>> would opt out to serialization/deserialization as a c
On 15 Apr 2011, at 18:00, Olaf Bergner wrote:
> Am 15.04.11 16:56, schrieb Manik Surtani:
>> On 11 Apr 2011, at 13:13, Galder Zamarreño wrote:
>>
>>> - Rather than modifying PutKeyValueCommand, it might be better to subclass
>>> it and add the large object logic there? i.e. PutLargeKeyValueComm
On 18 Apr 2011, at 10:57, Manik Surtani wrote:
> How do you generate the Long internalID of an XID?
I'va factorised the IdGenerator(now ClusterIdGenerator) galder wrote for
generating cluster-unique longs for HR's versioned operations.
>
> Another approach may be to take the byte[] (XID) a
On 18 Apr 2011, at 12:05, Mircea Markus wrote:
>> Another approach may be to take the byte[] (XID) and Base64 it. Then you
>> have a 1-to-1 mapping between the XID and a JMX-friendly String. :-) Or
>> maybe an SHA1 hash of the byte[].
> yes,that would work as well. A long is smaller and (not
FYI, EHCache uses optional recovery as well.
http://ehcache.org/documentation/jta.html#Failure_Recovery
On 11 Mar 2011, at 16:43, Mircea Markus wrote:
> Hi,
>
> I've updated tx recovery design document[1] after feedback received from
> Manik: the most relevant changed is that all recovery inf
I still think Mircea's suggestion is very valid. Try cloning first. If
cloning is not supported then serialize/deserialize. And in any case you only
need 1 copy of the callable to send across to all other nodes, and the original
copy for local execution, right?
On 18 Apr 2011, at 11:24, Gal
Yes, that was somehow expected given the integration with Hibernate/2LC;
their API is very similar to ours, would be interesting to see some performance
comparison on this area.
On 18 Apr 2011, at 12:41, Manik Surtani wrote:
> FYI, EHCache uses optional recovery as well.
>
> http://ehcache.org/
They started the archival a couple months ago in response to my request,
but I simply forgot to tell you about this:
http://infinispan.markmail.org/search/
Enjoy, and say good bye to the ugly mailman archive. :-)
--
Trustin Lee, http://gleamynode.net/
signature.asc
Description: OpenPGP d
Awesome, thanks!
On 18 Apr 2011, at 13:31, 이희승 (Trustin Lee) wrote:
> They started the archival a couple months ago in response to my request,
> but I simply forgot to tell you about this:
>
>http://infinispan.markmail.org/search/
>
> Enjoy, and say good bye to the ugly mailman archive. :-)
On 11-04-18 7:58 AM, Manik Surtani wrote:
> I still think Mircea's suggestion is very valid. Try cloning first. If
> cloning is not supported then serialize/deserialize. And in any case you
> only need 1 copy of the callable to send across to all other nodes, and the
> original copy for local
Fair enough. Keep it simple.
On 18 Apr 2011, at 14:12, Vladimir Blagojevic wrote:
> On 11-04-18 7:58 AM, Manik Surtani wrote:
>> I still think Mircea's suggestion is very valid. Try cloning first. If
>> cloning is not supported then serialize/deserialize. And in any case you
>> only need 1
18 matches
Mail list logo
