Bela,
You are thinking something like Netty's composite byte buffer?
http://netty.io/4.0/guide/#architecture.5
On 5/23/13 2:09 PM, Manik Surtani wrote:
Bela,
We shouldn't need to wait for NIO2/JDK7 for this. We can do this in JDK6
as well, granted the impl may not be as good unless run on a
While adding changes for cache methods (entrySet, keySet, values, size) to
include passivated entries it had been pointed out to conditionally do these
operations if flags such as SKIP_CACHE_STORE and SKIP_CACHE_LOAD were provided.
Also does anyone have any feedback on if both flags should
] FlagAffectedCommand interface hierarchy
(ISPN-761)
On 31 May 2013 14:37, William Burns wbu...@redhat.com wrote:
While adding changes for cache methods (entrySet, keySet, values, size) to
include passivated entries it had been pointed out to conditionally do these
operations if flags
-dev@lists.jboss.org
Sent: Monday, June 3, 2013 9:24:46 AM
Subject: Re: [infinispan-dev] FlagAffectedCommand interface hierarchy
(ISPN-761)
On May 31, 2013, at 3:37 PM, William Burns wbu...@redhat.com wrote:
While adding changes for cache methods (entrySet, keySet, values, size) to
include
On Mon, Jun 17, 2013 at 11:11 AM, Dan Berindei dan.berin...@gmail.comwrote:
On Mon, Jun 17, 2013 at 3:58 PM, Pedro Ruivo pe...@infinispan.org wrote:
On 06/17/2013 12:56 PM, Mircea Markus wrote:
On 17 Jun 2013, at 11:52, Pedro Ruivo pe...@infinispan.org wrote:
I've been looking at
On Tue, Jun 18, 2013 at 9:23 AM, Dan Berindei dan.berin...@gmail.comwrote:
On Mon, Jun 17, 2013 at 6:35 PM, William Burns mudokon...@gmail.comwrote:
On Mon, Jun 17, 2013 at 11:11 AM, Dan Berindei dan.berin...@gmail.comwrote:
On Mon, Jun 17, 2013 at 3:58 PM, Pedro Ruivo pe
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:
AM, Pedro Ruivo pe...@infinispan.org wrote:
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
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
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
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
... However, I think that all the events should synchronize at some
point (update by remote get, update by local put and invalidation).
I was hoping that would cover this. Other than the outstanding issue
in ISPN-2965.
On Thu, Jun 27, 2013 at 9:18 AM, William Burns mudokon...@gmail.com wrote
Trying to leave my points that would most likely have responses to
second email so we can try to get back to a single thread :)
On Thu, Jun 27, 2013 at 4:12 PM, Dan Berindei dan.berin...@gmail.com wrote:
On Thu, Jun 27, 2013 at 4:18 PM, William Burns mudokon...@gmail.com wrote:
First off I
On Thu, Jun 27, 2013 at 4:40 PM, Dan Berindei dan.berin...@gmail.com wrote:
On Thu, Jun 27, 2013 at 4:40 PM, William Burns mudokon...@gmail.com wrote:
Comments that were outstanding on PR:
@danberindei:
+1 to move the discussion to the mailing list, could you summarize
your changes
On Fri, Jun 28, 2013 at 5:14 AM, Dan Berindei dan.berin...@gmail.com wrote:
On Fri, Jun 28, 2013 at 12:17 AM, William Burns mudokon...@gmail.com
wrote:
Trying to leave my points that would most likely have responses to
second email so we can try to get back to a single thread
On Tue, Jul 2, 2013 at 5:23 AM, Dan Berindei dan.berin...@gmail.com wrote:
On Fri, Jun 28, 2013 at 4:39 PM, William Burns mudokon...@gmail.com wrote:
On Fri, Jun 28, 2013 at 5:14 AM, Dan Berindei dan.berin...@gmail.com
wrote:
On Fri, Jun 28, 2013 at 12:17 AM, William Burns mudokon
On Wed, Jul 3, 2013 at 5:28 AM, Dan Berindei dan.berin...@gmail.com wrote:
On Tue, Jul 2, 2013 at 9:51 PM, Pedro Ruivo pe...@infinispan.org wrote:
On 07/02/2013 04:55 PM, Dan Berindei wrote:
On Tue, Jul 2, 2013 at 6:35 PM, Pedro Ruivo pe...@infinispan.org
On Tue, Jul 9, 2013 at 9:35 AM, Dan Berindei dan.berin...@gmail.com wrote:
On Mon, Jul 8, 2013 at 12:19 AM, Sanne Grinovero sa...@infinispan.org
wrote:
On 3 July 2013 10:26, Dan Berindei dan.berin...@gmail.com wrote:
On Tue, Jul 2, 2013 at 8:41 PM, Sanne Grinovero
On Thu, Jul 11, 2013 at 1:23 AM, Mircea Markus mmar...@redhat.com wrote:
On 27 Jun 2013, at 16:18, William Burns mudokon...@gmail.com wrote:
First off I apologize for the length.
There have been a few Jiras recently that have identified L1 consistency
issues with both TX and non TX sync
It should definitely be on a per loader/store level. Looking through
the ispn server it allows for shared to be configured on each
loader/store instance, so depending on the ordering will determine
whether they are shared or not.
On Fri, Aug 9, 2013 at 1:11 AM, Dan Berindei
I was recently refactoring code dealing with isolation levels and
found how ReadCommitted is implemented and I have a few concerns I
wanted to bring up.
ReadCommitted read operations work by storing a reference to the value
from the data store in its caller's context. Thus whenever another
Responses inline
Also want to preface this with: If you haven't seen in other mailing
list Read Committed is going away as it doesn't work properly in DIST
(in fact AM is is really badly bugged with RC with DIST);
On Fri, Sep 20, 2013 at 9:56 AM, Emmanuel Bernard
emman...@hibernate.org wrote:
I
On Sat, Sep 21, 2013 at 3:33 PM, Sanne Grinovero sa...@infinispan.org wrote:
On 20 September 2013 23:19, William Burns mudokon...@gmail.com wrote:
Responses inline
Also want to preface this with: If you haven't seen in other mailing
list Read Committed is going away as it doesn't work
, at 18:32, William Burns mudokon...@gmail.com wrote:
[Technically it would be awesome to be able to be able to rely on RR
but it doesn't work as in databases - it doesn't snapshot the version
of entries not touched yet - so we have to compensate at a higher
layer..]
The repeatable read
Looking at ISPN-3557, I think that is resolved by ISPN-3560. It was
just a bug in the commands not using the context values properly. I
will look closer tomorrow, but I am pretty sure it is resolved (can
just add tests for PR).
I am guessing you are talking about ISPN-3558. Either way, I agree
Dear Infinispan community,
We are proud to announce the first candidate release for Infinispan 6.0.0.
As many of you would expect from a candidate release this version
contains a multitude of bug fixes/enhancements to get to a stable
6.0.0 release.
For a complete list of features and fixes
I agree, and I could have sworn there was a JIRA that detailed this,
but I can't seem to locate it now. I was hoping to get to it next
release.
This also is a very big improvement for non tx caches as well as the
updating cache only has to send a single message, possibly reducing
the overall
On Tue, Oct 29, 2013 at 12:58 PM, Dan Berindei dan.berin...@gmail.com wrote:
On Tue, Oct 29, 2013 at 3:56 PM, Mircea Markus mmar...@redhat.com wrote:
On Oct 29, 2013, at 3:08 PM, William Burns mudokon...@gmail.com wrote:
I agree, and I could have sworn there was a JIRA that detailed
Since it seems I can't comment on the wiki itself, I am just replying here.
I wonder if the third option 'Primary partition' is desirable. I
think availability in some cases would be harmed more than we would
like.
Lets say you have a 5 node cluster where 3 of the nodes are behind the
same
I don't know this sounds like a pretty good idea to me ;)
http://www.adbroad.com/2009/07/need-proofreader-hire-monkey.html
- Will
On Thu, Nov 14, 2013 at 12:39 PM, Mircea Markus mmar...@redhat.com wrote:
Nice idea!
Can you check if one of them can offer an free subscription for OSS software?
I wonder if we are over analyzing this. It seems the main issue is
that the replication is done asynchronously. Infinispan has many ways
to be make something asynchronous. In my opinion we just chose the
wrong way. Wouldn't it be easier to just change the PFER to instead
of passing along the
key. So there's nothing stopping the
PFER from writing its value after a regular (sync) put when the put
was initiated after the PFER.
On Fri, Nov 22, 2013 at 2:49 PM, William Burns mudokon...@gmail.com
mailto:mudokon...@gmail.com wrote:
I wonder if we are over
Hello everyone,
I wanted to discuss what I would say as dubious benefit of L1OnRehash
especially compared to the benefits it provide.
L1OnRehash is used to retain a value by moving a previously owned
value into the L1 when a rehash occurs and this node no longer owns
that value Also any current
+1 to moving to the async methods only. I have mentioned this as well
in passing when discussing L1 as there is no way to ensure consistency
with an async transport. Although if we fire the async methods with
either SKIP_REMOTE_LOOKUP/IGNORE_RETURN_VALUES flag than this
consistency is still lost
On Mon, Feb 3, 2014 at 9:54 AM, Sanne Grinovero sa...@infinispan.org wrote:
On 3 February 2014 14:10, Radim Vansa rva...@redhat.com wrote:
See below...
On Fri, Jan 31, 2014 at 7:35 AM, Radim Vansa rva...@redhat.com wrote:
Worth to note that Infinispan does not have true async operation -
On Mon, Feb 3, 2014 at 11:07 AM, Galder Zamarreño gal...@redhat.com wrote:
On 23 Jan 2014, at 18:54, Mircea Markus mmar...@redhat.com wrote:
On Jan 23, 2014, at 5:48 PM, William Burns mudokon...@gmail.com wrote:
Hello all,
I have been working with notifications and most recently I have
On Tue, Feb 4, 2014 at 6:04 AM, Dan Berindei dan.berin...@gmail.com wrote:
On Tue, Feb 4, 2014 at 10:07 AM, Galder Zamarreño gal...@redhat.com wrote:
On 28 Jan 2014, at 15:29, William Burns mudokon...@gmail.com wrote:
Hello everyone,
I wanted to discuss what I would say as dubious
On Mon, Feb 17, 2014 at 7:53 AM, Sanne Grinovero sa...@infinispan.org wrote:
On 12 February 2014 10:40, Mircea Markus mmar...@redhat.com wrote:
Hey Will,
With the current design, during a topology change, an event might be
delivered twice to a cluster listener. I think we might be able to
Hello everyone,
I am happy to announce that the latest Infinispan 7.0.0.Alpha1 build
has the first pass of Cluster Listeners implemented.
You can read all about the details at the blog post [1].
You can get the latest build of Infinispan from our site [2].
Try it out and let us know what you
of to listener,
right? So how do you define method on listener to be invoked with
converted object C as a parameter?
On 3/5/2014, 10:02 AM, William Burns wrote:
Hello everyone,
I am happy to announce that the latest Infinispan 7.0.0.Alpha1 build
has the first pass of Cluster Listeners
On Wed, Mar 12, 2014 at 3:12 PM, Paul Ferraro paul.ferr...@redhat.com wrote:
On Wed, 2014-03-12 at 18:45 +0100, Galder Zamarreño wrote:
On 05 Mar 2014, at 18:16, Mircea Markus mmar...@redhat.com wrote:
Sanne came with a good follow up to this email, just some small
clarifications:
On
Recently while working on some ISPN 7 features, there were some public
API inconsistencies. I wanted to bring these up just in case if
someone had concerns.
The first few are pretty trivial, but can cause compilation errors
between versions if user code implements these interfaces and defines
the
Metadata class, which doesn't live in the commons package. I didn't
want to separate the 2 filter classes. And unfortunately the Metadata
class relies on other classes in core, so that isn't easy to move over
either, but doable :( WDYT?
Cheers,
Pedro
On 03/13/2014 12:07 PM, William Burns
On Thu, Mar 13, 2014 at 8:37 AM, Pedro Ruivo pe...@infinispan.org wrote:
On 03/13/2014 12:35 PM, William Burns wrote:
On Thu, Mar 13, 2014 at 8:31 AM, Pedro Ruivo pe...@infinispan.org wrote:
Hi,
#1 and #2 are ok to me but, IMO, the filter package should be in commons
module
Sorry I
KeyValueFilter though ?
- Will
Vladimir
On 3/13/2014, 8:35 AM, William Burns wrote:
On Thu, Mar 13, 2014 at 8:31 AM, Pedro Ruivo pe...@infinispan.org wrote:
Hi,
#1 and #2 are ok to me but, IMO, the filter package should be in commons
module
Sorry I forgot to detail why I said core. I
On Thu, Mar 13, 2014 at 11:54 AM, Vladimir Blagojevic
vblag...@redhat.com wrote:
On 3/13/2014, 11:39 AM, William Burns wrote:
On Thu, Mar 13, 2014 at 11:14 AM, Vladimir Blagojevic
vblag...@redhat.com wrote:
Mircea and I wanted to promote AdvancedCacheLoader.KeyFilter or merge
it with one
this after the issues are merged in to update the Infinispan upgrade
guide.
Thanks for bringing this up.
On 13 March 2014 12:45, William Burns mudokon...@gmail.com wrote:
On Thu, Mar 13, 2014 at 8:37 AM, Pedro Ruivo pe...@infinispan.org wrote:
On 03/13/2014 12:35 PM, William Burns wrote
While working on ISPN-4068 to add the current state to listeners that
were added I found that what I essentially needed was a way to iterate
over the entries of the cache. I am thinking of adding this to the
public API available on the AdvancedCache interface.
I wanted to get your guy's opinions
the version of the snapshot in the request
command.
The reason I was saying not to support this for tx right now, is
because of repeatable read, there is no way we can hold all the values
of the cache in the current context.
My 2c
Radim
On 03/17/2014 02:30 PM, William Burns wrote:
While working
On 17 March 2014 15:02, William Burns mudokon...@gmail.com wrote:
On Mon, Mar 17, 2014 at 10:45 AM, Radim Vansa rva...@redhat.com wrote:
Why listeners are not invoked? JCache iterator() notifies the listeners.
Like I mentioned this can be changed. However, I have not seen a
cache entry
On Fri, Apr 4, 2014 at 3:29 AM, Radim Vansa rva...@redhat.com wrote:
Hi,
I still don't think that the document covers properly the description of
failover.
My understanding is that client registers clustered listeners on one server
(the first one it connects, I guess). There's some space
On Fri, Apr 11, 2014 at 8:36 AM, Galder Zamarreño gal...@redhat.com wrote:
On 04 Apr 2014, at 19:11, William Burns mudokon...@gmail.com wrote:
On Fri, Apr 4, 2014 at 3:29 AM, Radim Vansa rva...@redhat.com wrote:
Hi,
I still don't think that the document covers properly the description
, but the discussion has
always dissolved. I haven't seen the final NO”.
Radim
On 04/11/2014 02:36 PM, Galder Zamarreño wrote:
On 04 Apr 2014, at 19:11, William Burns mudokon...@gmail.com wrote:
On Fri, Apr 4, 2014 at 3:29 AM, Radim Vansa rva...@redhat.com wrote:
Hi,
I still don't think
Was wondering if anyone had any opinions on the API for this.
These are a few options that Dan and I mulled over:
Note the CloseableIterable inteface mentioned is just an interface
that extends both Closeable and Iterable.
1. The API that is very similar to previously proposed in this list
but
On Thu, May 1, 2014 at 8:59 AM, Sanne Grinovero sa...@infinispan.org wrote:
On 30 April 2014 15:06, William Burns mudokon...@gmail.com wrote:
Was wondering if anyone had any opinions on the API for this.
These are a few options that Dan and I mulled over:
Note the CloseableIterable inteface
On Tue, May 13, 2014 at 9:10 AM, Pierre Sutra pierre.su...@unine.ch wrote:
Hello,
As part of the LEADS project, we have been using recently the clustered
listeners API. In our use case, the application is employing a few
thousands listeners, constantly installing and un-installing them.
Are
On Fri, Jun 6, 2014 at 8:51 AM, Emmanuel Bernard emman...@hibernate.org wrote:
We expect the same semantic as a RDBMS in READ_COMMITTED. getGroup() would be
equivalent to a select * from ASSOC_TABLE where owner_id = 2. Phantom reads
would be acceptable.
Yeah we can't currently stop any
On Fri, Jun 6, 2014 at 9:33 AM, Emmanuel Bernard emman...@hibernate.org wrote:
On 06 Jun 2014, at 15:29, Emmanuel Bernard emman...@hibernate.org wrote:
On 06 Jun 2014, at 15:04, William Burns mudokon...@gmail.com wrote:
Does that answer your question? Because I’m not sure what you mean
I was able to look into the details with this a bit. At first thought
I would think having a module that both the client and server packages
could both depend on would be best. However the issue is that these
factories produce instances that implement interfaces that live in the
core package,
I must admit this seems a bit heavy handed to have to enable
transactions, when are using them solely for the purpose of having
implicit transactions.
Can we not instead just tweak the NonTransactionalLockingInterceptor
to obey the FORCE_WRITE_LOCK, so it would guarantee a consistent value
in the
On Fri, Jun 27, 2014 at 8:54 AM, Mircea Markus mmar...@redhat.com wrote:
Still 2 failures on CI machine so no release yet[1].
Dan/Will please take a look.
[1]
http://ci.infinispan.org/viewLog.html?buildId=9237tab=buildResultsDivbuildTypeId=bt8
Yeah I logged [1] for this a bit ago. I was
On Fri, Jul 4, 2014 at 10:41 AM, Pierre Sutra pierre.su...@unine.ch wrote:
Hello,
Are you talking about non clustered listeners? It seems unlikely you
would need so many cluster listeners. Cluster listeners should allow
you to only install a small amount of them, usually you would have
only
I am assuming that you were using a shared cache loader without
passivation? In that case the size method will return all the entries
in the cache properly (albeit using a large amount of memory)
To be honest I can't think of a way to get an accurate count of what
is in the cache unless you are
Dear Infinispan community,
We are proud to announce the first beta release for Infinispan 7.0.0.
More info at
http://blog.infinispan.org/2014/08/infinispan-700beta1-is-out.html
Thanks to everyone for their involvement and contributions!
- Will
___
On Tue, Aug 26, 2014 at 2:23 PM, Sanne Grinovero sa...@infinispan.org wrote:
On 26 August 2014 18:38, William Burns mudokon...@gmail.com wrote:
On Mon, Aug 25, 2014 at 3:46 AM, Dan Berindei dan.berin...@gmail.com wrote:
On Mon, Aug 25, 2014 at 10:26 AM, Galder Zamarreño gal...@redhat.com
On Tue, Aug 26, 2014 at 3:17 PM, Sanne Grinovero sa...@infinispan.org wrote:
On 26 August 2014 19:38, William Burns mudokon...@gmail.com wrote:
On Tue, Aug 26, 2014 at 2:23 PM, Sanne Grinovero sa...@infinispan.org
wrote:
On 26 August 2014 18:38, William Burns mudokon...@gmail.com wrote
+1
Actually while looking at [1] I encountered the same error you were
getting (not the same as the JIRA itself) and thought about how we
could remedy that issue on a get as well. Being able to detect this
new CacheStoppingException would allow for some options.
[1]
On Fri, Sep 19, 2014 at 12:39 PM, Emmanuel Bernard
emman...@hibernate.org wrote:
On 19 Sep 2014, at 17:09, William Burns mudokon...@gmail.com wrote:
Comments regarding embedded usage are inline. I am not quite sure on
the hot rod client ones.
On Thu, Sep 18, 2014 at 12:24 PM, Emmanuel
On Thu, Sep 18, 2014 at 1:37 PM, Radim Vansa rva...@redhat.com wrote:
On 09/18/2014 07:21 PM, William Burns wrote:
On Thu, Sep 18, 2014 at 4:11 AM, Galder Zamarreño gal...@redhat.com
wrote:
Radim, adding -dev list since others might have the same qs:
@Will, some important information below
On Tue, Sep 23, 2014 at 12:12 PM, Galder Zamarreño gal...@redhat.com wrote:
On 22 Sep 2014, at 19:23, William Burns mudokon...@gmail.com wrote:
On Fri, Sep 19, 2014 at 12:39 PM, Emmanuel Bernard
emman...@hibernate.org wrote:
On 19 Sep 2014, at 17:09, William Burns mudokon...@gmail.com wrote
emman...@hibernate.org wrote:
You lost me at actually ;) but if you have some code or even a gist showing
how a user would use and interact with these changes, I can give you some
feedback on the use cases I had in mind and if they fit.
On 25 sept. 2014, at 15:20, William Burns mudokon
On Tue, Oct 7, 2014 at 7:32 AM, Radim Vansa rva...@redhat.com wrote:
If you have one local and one shared cache store, how should the command
behave?
a) distexec/MR sum of cache.withFlags(SKIP_REMOTE_LOOKUP,
SKIP_BACKUP_ENTRIES).size() from all nodes? (note that there's no
On Tue, Oct 7, 2014 at 8:43 AM, Radim Vansa rva...@redhat.com wrote:
On 10/07/2014 02:21 PM, William Burns wrote:
On Tue, Oct 7, 2014 at 7:32 AM, Radim Vansa rva...@redhat.com wrote:
If you have one local and one shared cache store, how should the command
behave?
a) distexec/MR sum
So it seems we would want to change this for 7.0 if possible since it
would be a bigger change for something like 7.1 and 8.0 would be even
further out. I should be able to put this together for CR2.
It seems that we want to implement keySet, values and entrySet methods
using the entry iterator
On Wed, Oct 8, 2014 at 10:57 AM, Dan Berindei dan.berin...@gmail.com wrote:
On Wed, Oct 8, 2014 at 5:42 PM, William Burns mudokon...@gmail.com wrote:
So it seems we would want to change this for 7.0 if possible since it
would be a bigger change for something like 7.1 and 8.0 would be even
I had forgotten about expiration also
being a problem). Otherwise we could just leave size() as it is now, it's
pretty fast :)
Radim
[1] https://issues.jboss.org/browse/ISPN-3202
On 10/08/2014 04:42 PM, William Burns wrote:
So it seems we would want to change this for 7.0 if possible
Actually this was something I was hoping to get to possibly in the near future.
I already have to do https://issues.jboss.org/browse/ISPN-4358 which
will require rewriting parts of the distributed entry iterator. In
doing so I was planning on breaking this out to a more generic
framework where
that
in the original implementation [a]
[a] https://issues.jboss.org/browse/ISPN-4643
Radim
[1] https://issues.jboss.org/browse/ISPN-3202
On 10/08/2014 04:42 PM, William Burns wrote:
So it seems we would want to change this for 7.0 if possible since it
would be a bigger change for something like
On Wed, Oct 8, 2014 at 12:23 PM, Dan Berindei dan.berin...@gmail.com wrote:
On Wed, Oct 8, 2014 at 6:14 PM, William Burns mudokon...@gmail.com wrote:
On Wed, Oct 8, 2014 at 10:57 AM, Dan Berindei dan.berin...@gmail.com
wrote:
On Wed, Oct 8, 2014 at 5:42 PM, William Burns mudokon
at 9:01 PM, Mircea Markus mmar...@redhat.com
wrote:
On Oct 10, 2014, at 17:30, William Burns mudokon...@gmail.com wrote:
Also we didn't really talk about the fact that these methods would
ignore ongoing transactions and if that is a concern or not.
It might be a concern
was. I have created [1] to track it.
[1] https://issues.jboss.org/browse/ISPN-4850
Emmanuel
On 30 Sep 2014, at 18:13, William Burns mudokon...@gmail.com wrote:
I have put it on a branch on github and you can try it out and let me
know what you think.
I still have a few things I may want
://blog.infinispan.org/2014/11/why-doesnt-mapsize-return-size-of.html
On Tue, Oct 14, 2014 at 8:11 AM, William Burns mudokon...@gmail.com wrote:
On Tue, Oct 14, 2014 at 3:33 AM, Dan Berindei dan.berin...@gmail.com wrote:
On Tue, Oct 14, 2014 at 9:55 AM, Radim Vansa rva...@redhat.com wrote:
On 10/13/2014 05
On Thu, Nov 13, 2014 at 7:59 AM, Dan Berindei dan.berin...@gmail.com wrote:
Radim, I also knew the 1.7 ForkJoinPool isn't really optimized for blocking
tasks, but the ManagedBlocker interface mentioned in [3] seems to be
intended just for that.
I was actually writing this same thing about
Hello everyone,
The final release is now available for 7.1.0, providing some
additional features and enhancements.
You can find out all about it at:
http://blog.infinispan.org/2015/01/infinispan-710-final-released.html
Thanks !
- Will Burns
___
Hello everyone,
I was on PTO and holiday the past couple weeks.
On the 22nd and 23rd I worked on:
ISPN-5104
ISPN-5088
both of which are in 7.0.3 now too. Also had to do some porting of prod work
This week I will start working on:
ISPN-5095
ISPN-3023
On Wed, Jan 7, 2015 at 5:17 AM, Ion
I am nearing completion of the new multi get command [1], allowing for
more efficient retrieval of multiple keys at the same time. Thanks
again to Radim for a lot of the initial work.
In doing so though I want to make sure I get feedback on how we want
the API to actually look, since this is
On Thu, Feb 26, 2015 at 3:57 AM, Galder Zamarreño gal...@redhat.com wrote:
Hey Will,
I wanted to ask you about the classes in org.infinispan.filter package.
I thought we agreed to get rid of these duplicate classes before 7.0.0.Final:
- org.infinispan.filter.Converter
-
would never have to do any casting.
Cheers,
Sanne
On 26 March 2015 at 10:04, Radim Vansa rva...@redhat.com wrote:
On 03/26/2015 10:28 AM, Galder Zamarreño wrote:
Comments inline:
On 24 Mar 2015, at 14:22, William Burns mudokon...@gmail.com wrote:
I am nearing completion of the new multi
That is a good point, Galder. Unfortunately the return type is lost since
we only pass a name for the filterconverter factory instead of the
converter which contains the type. We would have to allow the code to
specify the type in the assigned variable it is returned to or ask for a
Class
Just a quick clarification. The multi-get is only available for the
embedded API (remote should be coming into master next week). The
multi-put however is available for both embedded and remote cache.
Hope you enjoy the new changes!
- Will
On Fri, Apr 17, 2015 at 6:42 PM Sanne Grinovero
On Tue, Jun 9, 2015 at 2:12 AM Galder Zamarreño gal...@redhat.com wrote:
On 8 Jun 2015, at 10:57, Radim Vansa rva...@redhat.com wrote:
On 06/08/2015 10:41 AM, Dan Berindei wrote:
On Mon, Jun 8, 2015 at 10:37 AM, Galder Zamarreño gal...@redhat.com
wrote:
On 5 Jun 2015, at 14:15, Radim
On Tue, Jun 16, 2015 at 8:23 AM Sanne Grinovero sa...@infinispan.org
wrote:
Hi all,
we recently discussed about the problem of modelling locks as Java
locks, and blocking our actual threads - or have to delegate to
internal large threadpools - to model the parking of a thread which
is
but it's
not relaxing the consistency and transactional guarantees which we
normally provide with other cache modes.
We could of course argue if it could be useful to provide a relaxed
consistency mode, but I'd really not drop the stronger model.
-- Sanne
On 17 June 2015 at 19:32, William
Recently [1] was found. The underlying cause is that now initial state
transfer is enabled by default including invalidation caches.
When thinking about this I didn't even realize that we utilize a Replicated
consistent hash for invalidation mode. This all strikes me as just wrong.
To me an
Hello community,
Infinispan 8.0.0.Alpha2 is now available! Please check the blog [1] for
all the yummy details.
Cheers,
- Will
[1] http://blog.infinispan.org/2015/06/infinispan-800alpha2.html
___
infinispan-dev mailing list
Hello everyone,
I wanted to let you know I wrote up a design documenting the successor to
EntryRetriever, Distributed Streams [1] !
Any comments or feedback would be much appreciated.
I especially would like targeted feedback regarding:
1. The operators forEach and peek may want to be ran
on
approximation of size compared to element count [Resolved (Done)
Enhancement, Major, William Burns]
https://issues.jboss.org/browse/ISPN-5345
16:04:45 ttarrant after a few iterations about how it should look,
dberindei and I came to an agreement :)
16:05:43 ttarrant next up I
needed to run?
And since we know to watch out for the binary compatibility we can make
sure it stays that way for the 8.0 Final release.
Radim
[1] https://github.com/hibernate/hibernate-orm/pull/1045
On 08/06/2015 04:17 PM, William Burns wrote:
On Thu, Aug 6, 2015 at 4:42 AM Tristan
It seems ORM was compiled with a version earlier than Beta1 but then ran
with Beta2? The keySet method was changed to return a subclass of
CloseableIteratorSet with Beta2 to support distributed streams [1].
[1]
On Thu, Aug 6, 2015 at 4:42 AM Tristan Tarrant ttarr...@redhat.com wrote:
On 06/08/2015 10:30, Sanne Grinovero wrote:
On 6 August 2015 at 03:01, William Burns mudokon...@gmail.com wrote:
It seems ORM was compiled with a version earlier than Beta1 but then ran
with Beta2? The keySet
1 - 100 of 194 matches
Mail list logo
