On Mar 21, 2013, at 3:10 PM, Dan Berindei wrote:
>
>
> On Thu, Mar 21, 2013 at 1:17 PM, Galder Zamarreño wrote:
>
> On Mar 20, 2013, at 11:52 AM, Manik Surtani wrote:
>
> >
> > On 18 Mar 2013, at 12:21, Galder Zamarreño wrote:
> >
> >> This is why, I've created a new CHM, based on the CHM
I wrote some of these replies while offline… before I had seen your email :)
On Mar 21, 2013, at 2:07 PM, Tristan Tarrant wrote:
> Didn't I just say exactly that ? I don't understand where we differ.
>
> Tristan
>
> On 03/20/2013 12:25 PM, Sanne Grinovero wrote:
>> Why would you need to *store
On Thu, Mar 21, 2013 at 1:17 PM, Galder Zamarreño wrote:
>
> On Mar 20, 2013, at 11:52 AM, Manik Surtani wrote:
>
> >
> > On 18 Mar 2013, at 12:21, Galder Zamarreño wrote:
> >
> >> This is why, I've created a new CHM, based on the CHMv8, called
> ComparingConcurrentHashMapv8 (thx Tristan for th
On Mar 20, 2013, at 11:25 AM, Sanne Grinovero wrote:
> Why would you need to *store* anything which is equal for all entries?
^ It's not, necessarily. lifespan/maxIdle can be different for each entry.
Version is most likely different per entry.
> I'd have an interceptor "decorate" stuff with
On Mar 20, 2013, at 11:04 AM, Tristan Tarrant wrote:
> On 03/20/2013 11:51 AM, Manik Surtani wrote:
>> On 18 Mar 2013, at 12:21, Galder Zamarreño wrote:
>>
>>> IOW, you'll be able to say: create an Infinsipan Server that has String as
>>> key and value of type X, where X is the actual data ty
Didn't I just say exactly that ? I don't understand where we differ.
Tristan
On 03/20/2013 12:25 PM, Sanne Grinovero wrote:
> Why would you need to *store* anything which is equal for all entries?
> I'd have an interceptor "decorate" stuff with some constant additions;
> otherwise you could also
On Mar 20, 2013, at 11:51 AM, Manik Surtani wrote:
>
> On 18 Mar 2013, at 12:21, Galder Zamarreño wrote:
>
>> IOW, you'll be able to say: create an Infinsipan Server that has String as
>> key and value of type X, where X is the actual data type, no metadata!! The
>> metadata (version, encod
On Mar 20, 2013, at 11:52 AM, Manik Surtani wrote:
>
> On 18 Mar 2013, at 12:21, Galder Zamarreño wrote:
>
>> This is why, I've created a new CHM, based on the CHMv8, called
>> ComparingConcurrentHashMapv8 (thx Tristan for the name!). The work for this
>> can be seen
>> in:https://github.c
On Mar 20, 2013, at 10:49 AM, Sanne Grinovero wrote:
> Great stuff. Another benefit to keep in mind is that this can make it
> easy to use equality defined as identity of objects (the "=="):
> something I'm looking forward for, as with all use cases I'm familiar
> with (Lucene Directory + Hibern
On Mar 19, 2013, at 8:56 PM, Mircea Markus wrote:
>
> On 18 Mar 2013, at 12:21, Galder Zamarreño wrote:
>
>> Hi all,
>>
>> A heads up on what is going on with https://issues.jboss.org/browse/ISPN-2281
>>
>> While discussing this, Tristan and I came to the conclusion that we could
>> avoid t
onday, March 18, 2013 3:39:05 PM
> | Subject: Re: [infinispan-dev] Bye bye wrappers,
> ComparingConcurrentHashMapv8 is here (ISPN-2281)
> |
> | On 03/18/2013 01:21 PM, Galder Zamarreño wrote:
> | > Hi all,
> | >
> | > A heads up on what is going on with
> | &
On 20 Mar 2013, at 10:50, Manik Surtani wrote:
>>>
>>> This is why, I've created a new CHM, based on the CHMv8, called
>>> ComparingConcurrentHashMapv8 (thx Tristan for the name!). The work for this
>>> can be seen
>>> in:https://github.com/galderz/infinispan/commit/351e29d327d163ca8e941edf87
Why would you need to *store* anything which is equal for all entries?
I'd have an interceptor "decorate" stuff with some constant additions;
otherwise you could also think of reusing instances, like I had
suggested a while back to change the Externalizer contract to allow it
to be passed some cont
On 03/20/2013 11:51 AM, Manik Surtani wrote:
> On 18 Mar 2013, at 12:21, Galder Zamarreño wrote:
>
>> IOW, you'll be able to say: create an Infinsipan Server that has String as
>> key and value of type X, where X is the actual data type, no metadata!! The
>> metadata (version, encoding, whatever
On 18 Mar 2013, at 12:21, Galder Zamarreño wrote:
> This is why, I've created a new CHM, based on the CHMv8, called
> ComparingConcurrentHashMapv8 (thx Tristan for the name!). The work for this
> can be seen
> in:https://github.com/galderz/infinispan/commit/351e29d327d163ca8e941edf873f6d46b43
On 18 Mar 2013, at 12:21, Galder Zamarreño wrote:
> IOW, you'll be able to say: create an Infinsipan Server that has String as
> key and value of type X, where X is the actual data type, no metadata!! The
> metadata (version, encoding, whatever is requried to fulfill the
> compatibility reqs
On 19 Mar 2013, at 19:56, Mircea Markus wrote:
>>
>>
>> Doing the latter was relatively simple (I have this stashed), but having a
>> CHM that could take a byte[] as key wasn't that easy, since we can't change
>> JDK CHM.
> why's that? copyright?
A lot of JDK CHM code is private or package
Great stuff. Another benefit to keep in mind is that this can make it
easy to use equality defined as identity of objects (the "=="):
something I'm looking forward for, as with all use cases I'm familiar
with (Lucene Directory + Hibernate OGM) we should be able to maintain
uniqueness of instances p
On 18 Mar 2013, at 12:21, Galder Zamarreño wrote:
> Hi all,
>
> A heads up on what is going on with https://issues.jboss.org/browse/ISPN-2281
>
> While discussing this, Tristan and I came to the conclusion that we could
> avoid the need to create some wrappers required to fulfill requirements
infinispan -Dev List"
| Sent: Monday, March 18, 2013 3:39:05 PM
| Subject: Re: [infinispan-dev] Bye bye wrappers, ComparingConcurrentHashMapv8
is here (ISPN-2281)
|
| On 03/18/2013 01:21 PM, Galder Zamarreño wrote:
| > Hi all,
| >
| > A heads up on what is going on with
| > http
On 03/18/2013 01:21 PM, Galder Zamarreño wrote:
> Hi all,
>
> A heads up on what is going on with https://issues.jboss.org/browse/ISPN-2281
>
> While discussing this, Tristan and I came to the conclusion that we could
> avoid the need to create some wrappers required to fulfill requirements in
>
Hi all,
A heads up on what is going on with https://issues.jboss.org/browse/ISPN-2281
While discussing this, Tristan and I came to the conclusion that we could avoid
the need to create some wrappers required to fulfill requirements in this JIRA,
and as a side effect, reduce the memory consumpti
22 matches
Mail list logo
