On Jun 13, 2013, at 2:40 PM, Dan Berindei dan.berin...@gmail.com wrote:
On Wed, Jun 12, 2013 at 3:39 PM, Mircea Markus mmar...@redhat.com wrote:
On 12 Jun 2013, at 13:14, Galder Zamarreño gal...@redhat.com wrote:
On Jun 10, 2013, at 12:01 PM, Adrian Nistor anis...@redhat.com wrote:
If I run the whole test suite with OpenJDK 1.7, do I still need to set the
JAVA_HOME_7 variable?
On Wed, Jun 19, 2013 at 11:47 AM, Galder Zamarreño gal...@redhat.comwrote:
Hi all,
Starting with Infinispan 5.3.0.CR2, anyone who builds Infinispan requires
an environment variable called
I'd say yes... unless we force all developers to build with JDK7 making sure we
produce java 6 compiled classes...
On Jun 19, 2013, at 10:21 AM, Dan Berindei dan.berin...@gmail.com wrote:
If I run the whole test suite with OpenJDK 1.7, do I still need to set the
JAVA_HOME_7 variable?
On
I think we should.
Netty uses the maven-enforcer-plugin to force compilation with a JDK
1.7, animal-sniffer-maven-plugin to ensure that only classes available
in previous versions are used.
Tristan
On 06/19/2013 11:34 AM, Galder Zamarreño wrote:
I'd say yes... unless we force all developers
Agreed. https://issues.jboss.org/browse/ISPN-3242
On 19 Jun 2013, at 10:41, Tristan Tarrant ttarr...@redhat.com wrote:
I think we should.
Netty uses the maven-enforcer-plugin to force compilation with a JDK
1.7, animal-sniffer-maven-plugin to ensure that only classes available
in previous
All the L1 data for a DIST cache is stored in the same data container as
the actual distributed data itself. I wanted to propose breaking this out
so there is a separate data container for the L1 cache as compared to the
distributed data.
I thought of a few quick benefits/drawbacks:
Benefits:
I have often thought of this. Comments inline:
On 19 Jun 2013, at 13:44, William Burns mudokon...@gmail.com wrote:
All the L1 data for a DIST cache is stored in the same data container as the
actual distributed data itself. I wanted to propose breaking this out so
there is a separate data
Instinctively, this is a very attractive idea.
Would the L1 data container be a separate, but equal container? i.e.
would it be a separate instance from the DIST_SYNC cache but the exact same
data structure?
or
Would the L1 data container be separate, and different container? i.e.
would it
That would make *a lot* of sense :)
Cheers,
Paolo
On 6/19/13 1:44 PM, William Burns wrote:
All the L1 data for a DIST cache is stored in the same data container
as the actual distributed data itself. I wanted to propose breaking
this out so there is a separate data container for the L1
Hi
+1 :)
some comments inline.
Pedro
On 06/19/2013 02:16 PM, Manik Surtani wrote:
I have often thought of this. Comments inline:
On 19 Jun 2013, at 13:44, William Burns mudokon...@gmail.com
mailto:mudokon...@gmail.com wrote:
All the L1 data for a DIST cache is stored in the same data
This would only affect the Cache internals (use two DataContainers instead
of one). Users still won't have direct access to the L1 cache.
On Wed, Jun 19, 2013 at 4:24 PM, cotton-ben
ben.cot...@alumni.rutgers.eduwrote:
Instinctively, this is a very attractive idea.
Would the L1 data
Would the L1 data container be a separate, but equal container? i.e.
would it be a separate instance from the DIST_SYNC cache but the exact
same
data structure?
or
Would the L1 data container be separate, and different container? i.e.
would it be a completely different data structure (and
On 06/19/2013 02:46 PM, William Burns wrote:
+1 always having it be bounded would be really good. The configuration
could have a default and there could be a check to make sure they have
1 configured if provided. I don't know what would be the best default
here though? 64? 128? 1024?
I
On 19 June 2013 13:44, William Burns mudokon...@gmail.com wrote:
All the L1 data for a DIST cache is stored in the same data container as the
actual distributed data itself. I wanted to propose breaking this out so
there is a separate data container for the L1 cache as compared to the
/ William-Burns-3 wrote:
[...] My initial thought is that it would always use the same interface,
but we could add a specific implementation later if we found additional
optimizations./
/ Daniel Berendei wrote:
[...] Users still won't have direct access to the L1 cache./
Given that you guys
/
Benefits:
1. L1 cache can be separately tuned - L1 maxEntries for example
-1!
I don't think thats a benefit actually, from the point of view of a user:
[...]
At the opposite site, I don't see how - as a user - I could optimally
tune a separate container. /
There is 1 place where this
On 19 June 2013 15:35, cotton-ben ben.cot...@alumni.rutgers.edu wrote:
/
Benefits:
1. L1 cache can be separately tuned - L1 maxEntries for example
-1!
I don't think thats a benefit actually, from the point of view of a user:
[...]
At the opposite site, I don't see how - as a user - I
On Wed, Jun 19, 2013 at 10:19 AM, Sanne Grinovero sa...@infinispan.orgwrote:
On 19 June 2013 13:44, William Burns mudokon...@gmail.com wrote:
All the L1 data for a DIST cache is stored in the same data container as
the
actual distributed data itself. I wanted to propose breaking this out
/ Indeed, IFF you separate the two storage areas you get in that kind of
need, but I think it's an unnecessary complexity. The world is
actually quite simple [...]/
Thanks Sanne. Without going into any specific defense of a complexity
sometimes needed position, I agree with what you are saying
/At the opposite site, I don't see how - as a user - I could optimally
tune a separate container.
I agree that is more difficult to configure, this was one of my points as
both a drawback and benefit. It sounds like in general you don't
believe the benefits outweigh the drawbacks
On 19 June 2013 16:44, cotton-ben ben.cot...@alumni.rutgers.edu wrote:
/At the opposite site, I don't see how - as a user - I could optimally
tune a separate container.
I agree that is more difficult to configure, this was one of my points as
both a drawback and benefit. It sounds
On Wed, Jun 19, 2013 at 11:56 AM, Sanne Grinovero sa...@infinispan.orgwrote:
On 19 June 2013 16:44, cotton-ben ben.cot...@alumni.rutgers.edu wrote:
/At the opposite site, I don't see how - as a user - I could
optimally
tune a separate container.
I agree that is more difficult
I have to disagree ;-) It certainly is a fact that he's very well
intentioned to make enhancements, but I don't this strategy is proven
the be superior; I'm actually convinced of the opposite.
We simply cannot assume that the real data and the L1 stored entries
will have the same level of
I'm gonna suggest Hop Rod Rye, for obvious reasons:
http://beeradvocate.com/beer/profile/610/3158
-j
On Mon, Jun 17, 2013 at 1:37 PM, Mircea Markus mmar...@redhat.com wrote:
Hi,
Following the tradition, each Infinispan release is code is a beer.
Suggestions?
I'll start:
- Infinium
On 19 June 2013 17:17, William Burns mudokon...@gmail.com wrote:
On Wed, Jun 19, 2013 at 11:56 AM, Sanne Grinovero sa...@infinispan.org
wrote:
On 19 June 2013 16:44, cotton-ben ben.cot...@alumni.rutgers.edu wrote:
/At the opposite site, I don't see how - as a user - I could
On Wed, Jun 19, 2013 at 1:27 PM, Sanne Grinovero sa...@infinispan.orgwrote:
On 19 June 2013 17:17, William Burns mudokon...@gmail.com wrote:
On Wed, Jun 19, 2013 at 11:56 AM, Sanne Grinovero sa...@infinispan.org
wrote:
On 19 June 2013 16:44, cotton-ben ben.cot...@alumni.rutgers.edu
On Wed, Jun 19, 2013 at 5:19 PM, Sanne Grinovero sa...@infinispan.orgwrote:
On 19 June 2013 13:44, William Burns mudokon...@gmail.com wrote:
All the L1 data for a DIST cache is stored in the same data container as
the
actual distributed data itself. I wanted to propose breaking this out so
On 19 June 2013 19:00, Dan Berindei dan.berin...@gmail.com wrote:
On Wed, Jun 19, 2013 at 5:19 PM, Sanne Grinovero sa...@infinispan.org
wrote:
On 19 June 2013 13:44, William Burns mudokon...@gmail.com wrote:
All the L1 data for a DIST cache is stored in the same data container as
the
Ok chaps -
https://issues.jboss.org/browse/ISPN-2463 has been modified and I want to use
that as a primary tracker of what we're doing here. Let's try and keep the
sub-tasks as simple as possible so we can make sure we limit 1 PR -- 1
sub-task easily?
Also, should we move this to the
29 matches
Mail list logo
