On Tue, Feb 4, 2014 at 3:03 PM, Galder Zamarreño gal...@redhat.com wrote:
On 04 Feb 2014, at 13:50, Dan Berindei dan.berin...@gmail.com wrote:
On Tue, Feb 4, 2014 at 2:36 PM, Galder Zamarreño gal...@redhat.com
wrote:
Narrowing down the list now, since this is a problem of how our CI
, Dan Berindei dan.berin...@gmail.com wrote:
On Tue, Feb 4, 2014 at 3:03 PM, Galder Zamarreño gal...@redhat.com
wrote:
On 04 Feb 2014, at 13:50, Dan Berindei dan.berin...@gmail.com wrote:
On Tue, Feb 4, 2014 at 2:36 PM, Galder Zamarreño gal...@redhat.com
wrote:
Narrowing down
Hi Etienne
I was going to suggest using a combiner - the combiner would process the
mapper results from just one node, so you should need at most double the
memory on that node. I guess we could reduce the memory requirements even
more if the combiner could run concurrently with the mapper...
Radim, this is how our M/R algorithm works (Hadoop may do it differently):
* The mapping phase generates a MapIntKey, CollectionIntValue on each
node (Int meaning intermediate).
* In the combine (local reduce) phase, a combine operation takes as input
an IntKey and a CollectionIntValue with only
in
JIRA for this [2].
Cheers
Dan
[1] https://issues.jboss.org/browse/ISPN-4021
[2] https://issues.jboss.org/browse/ISPN-4022
Cheers,
Evangelos
On 02/18/2014 11:59 AM, Dan Berindei wrote:
Radim, this is how our M/R algorithm works (Hadoop may do it
differently):
* The mapping phase
On Tue, Feb 18, 2014 at 2:17 PM, Evangelos Vazaios vag...@gmail.com wrote:
On 02/18/2014 01:40 PM, Dan Berindei wrote:
On Tue, Feb 18, 2014 at 12:21 PM, Evangelos Vazaios vag...@gmail.com
wrote:
Hi Radim,
Since Hadoop is the most popular implementation of MapReduce I will give
On Tue, Feb 18, 2014 at 5:46 PM, Evangelos Vazaios vag...@gmail.com wrote:
On 02/18/2014 05:36 PM, Vladimir Blagojevic wrote:
On 2/18/2014, 4:59 AM, Dan Berindei wrote:
The limitation we have now is that in the reduce phase, the entire
list of values for one intermediate key must
On Tue, Feb 18, 2014 at 5:33 PM, Evangelos Vazaios vag...@gmail.com wrote:
On 02/18/2014 04:39 PM, Dan Berindei wrote:
On Tue, Feb 18, 2014 at 2:17 PM, Evangelos Vazaios vag...@gmail.com
wrote:
On 02/18/2014 01:40 PM, Dan Berindei wrote:
On Tue, Feb 18, 2014 at 12:21 PM, Evangelos
On Wed, Feb 19, 2014 at 1:03 PM, Sanne Grinovero sa...@infinispan.orgwrote:
On 19 February 2014 07:12, Galder Zamarreño gal...@redhat.com wrote:
On 03 Feb 2014, at 19:01, Dan Berindei dan.berin...@gmail.com wrote:
On Mon, Feb 3, 2014 at 6:28 PM, Radim Vansa rva...@redhat.com wrote
On Wed, Feb 19, 2014 at 5:26 PM, Vladimir Blagojevic vblag...@redhat.comwrote:
On 2/19/2014, 8:22 AM, Dan Berindei wrote:
Sorry, I didn't get too much from that example either, I gave up after
the second registering is fun popup :)
One last question: with Hadoop I imagine it's quite
On Mon, Feb 17, 2014 at 7:44 PM, William Burns mudokon...@gmail.com wrote:
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
On Mon, Feb 24, 2014 at 10:55 PM, Vladimir Blagojevic
vblag...@redhat.comwrote:
See inline
On 2/24/2014, 12:57 PM, Mircea Markus wrote:
On Feb 19, 2014, at 8:45 PM, Vladimir Blagojevic vblag...@redhat.com
wrote:
Hey guys,
As some of you might know we have received additional
On Tue, Feb 25, 2014 at 9:31 PM, Vladimir Blagojevic vblag...@redhat.comwrote:
Hey,
I am starting to like this thread more and more :-) In conclusion, for
distributed executors we are not adding any new APIs because Callable
implementers can already write to cache using existing API. We
On Wed, Feb 26, 2014 at 8:56 AM, Galder Zamarreño gal...@redhat.com wrote:
On 19 Feb 2014, at 12:03, Sanne Grinovero sa...@infinispan.org wrote:
On 19 February 2014 07:12, Galder Zamarreño gal...@redhat.com wrote:
On 03 Feb 2014, at 19:01, Dan Berindei dan.berin...@gmail.com wrote
Great job, Radim! Looking forward to Radargun 2.0!
On Wed, Feb 26, 2014 at 12:47 PM, Galder Zamarreño gal...@redhat.comwrote:
Great work Radim!!! Awesome job and very interesting roadmap :)
On 20 Feb 2014, at 15:40, Radim Vansa rva...@redhat.com wrote:
Hi all,
it has been a long time
On Wed, Feb 26, 2014 at 3:12 PM, Mircea Markus mmar...@redhat.com wrote:
On Feb 25, 2014, at 5:08 PM, Sanne Grinovero sa...@infinispan.org wrote:
There also is the opposite problem to be considered, as Emmanuel
suggested on 11/04/2012:
you can't forbid the user to store the same object
On Wed, Feb 26, 2014 at 4:24 PM, Tristan Tarrant ttarr...@redhat.comwrote:
On 26/02/2014 15:02, Mircea Markus wrote:
On Feb 26, 2014, at 1:05 PM, Tristan Tarrant ttarr...@redhat.com
wrote:
Dear all,
our JavaDocs currently encompass all of our classes, interfaces, etc
with no clear
Hi Sanne
Reading your reply I realized I was wrong in my evaluation, we could
require the user to specify the secure cache(s) he wants to query when
building the query and checking that he has read rights on all of them
before executing the query, just like a DB would do. And if he doesn't
On Thu, Feb 27, 2014 at 8:13 PM, Sanne Grinovero sa...@infinispan.orgwrote:
On 27 February 2014 16:58, Mircea Markus mmar...@redhat.com wrote:
On Feb 27, 2014, at 3:28 PM, Vladimir Blagojevic vblag...@redhat.com
wrote:
Hmm very good points Sanne. Yeah I think we can have a contract that
Dear Infinispan community,
We're proud to announce the first Alpha release of Infinispan 7.0.0.
This release adds several new features:
- Support for clustered listeners. One of the limitation of Infinispan's
distributed mode used to be that listeners could only receive events for
I got the OOM in the hotrod client testsuite as well today, and I have a
fix: https://github.com/infinispan/infinispan/pull/2433
On Fri, Mar 7, 2014 at 6:35 PM, Sanne Grinovero sa...@infinispan.orgwrote:
today core passed, but: the Infinispan Hot Rod Client seems to fail
because of an
On Thu, Mar 13, 2014 at 5:58 PM, William Burns mudokon...@gmail.com wrote:
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:
On Tue, Mar 18, 2014 at 9:58 AM, Radim Vansa rva...@redhat.com wrote:
What does exactly the configName refer to? Some cache name as it appears
in configuration, and then the intermediate cache will copy that
configuration and create new custom cache? That means, that configured
cache will
Hi Paul
On Wed, Mar 26, 2014 at 3:57 PM, Paul Ferraro paul.ferr...@redhat.com
wrote:
Hey guys,
I have created a number of requests for features that I'd like to be
able to leverage for WildFly 9/10. Can the appropriate component
owners
(which I think is Dan in all cases) comment on the
Don't we want to allow the user to pass some data to the filter factory
on registration?
Otherwise we'd force the user to write a separate filter factory class
every time they want to track changes to a single key.
Cheers
Dan
On Wed, Apr 2, 2014 at 2:14 PM, Galder Zamarreño
https://issues.jboss.org/browse/ISPN-720
Replace CacheEntryEvictedEvent with CacheEntriesEvictedEvent (note the
plural)
On Thu, Apr 3, 2014 at 11:31 AM, Radim Vansa rva...@redhat.com wrote:
Hi guys,
I've noticed that CacheEntryEvicted is marked as:
@deprecated Note that this annotation
On Wed, Apr 9, 2014 at 5:37 PM, Galder Zamarreño gal...@redhat.com
wrote:
On 03 Apr 2014, at 11:38, Radim Vansa rva...@redhat.com wrote:
Hi,
looking on the new configuration parser, I've noticed that you
cannot
configure ConsistentHashFactory anymore - is this by purpose?
^ Rather
On Tue, Apr 15, 2014 at 5:29 PM, Radim Vansa rva...@redhat.com wrote:
On 04/15/2014 02:31 PM, Galder Zamarreño wrote:
On 09 Apr 2014, at 19:38, Dan Berindei dan.berin...@gmail.com
wrote:
On Wed, Apr 9, 2014 at 5:37 PM, Galder Zamarreño
gal...@redhat.com wrote:
On 03 Apr 2014, at 11
On Tue, Apr 22, 2014 at 2:30 PM, Galder Zamarreño gal...@redhat.com
wrote:
On 17 Apr 2014, at 08:03, Radim Vansa rva...@redhat.com wrote:
On 04/16/2014 05:38 PM, William Burns wrote:
On Wed, Apr 16, 2014 at 11:14 AM, Galder Zamarreño
gal...@redhat.com wrote:
On 11 Apr 2014, at 15:25,
I'm not convinced that assuming that the user has the same compiler/c
runtime/c++ library/exception handling is such a big deal.
The users already have the sources; if we only ship a binary compiled
with VS2013 and they want to compile their project with VS2012, they
can recompile the C++
Radim, I would contend that the first and foremost guarantee that put()
makes is to leave the cache in a consistent state. So we can't just throw
an exception and give up, leaving k=v on one owner and k=null on another.
Secondly, put(k, v) being atomic means that it either succeeds, it writes
k=v
compromise; we can do better.
For example - as Radim suggested - it might seem reasonable to have
the older value around for a little while. We'll need a little bit of
history of values and tombstones anyway for many other reasons.
Sanne
On 12 May 2014 09:37, Dan Berindei dan.berin
On Tue, May 13, 2014 at 6:40 PM, Radim Vansa rva...@redhat.com wrote:
On 05/13/2014 03:58 PM, Dan Berindei wrote:
On Mon, May 12, 2014 at 1:54 PM, Radim Vansa rva...@redhat.com wrote:
@Dan: It's absolutely correct to do the further writes in order to make
the cache consistent, I am
I don't see a lot of value in doing core-only releases. Releases are
expensive because we have to update the website and documentation, and we
have to announce the release everywhere. Releasing only the core won't
change that.
Also, we don't try to maintain backwards compatibility between
Welcome Gustavo!
On Thu, May 15, 2014 at 5:17 PM, Adrian Nistor anis...@redhat.com wrote:
Welcome Gustavo!
On 05/15/2014 04:29 PM, Sanne Grinovero wrote:
Hi all,
today we finally have Gustavo joining us as a full time engineer on
Infinispan.
He worked with Tristan and myself in
Mohan, infinispan-server-hotrod.jar should have been built by the build
process itself.
I have just tried it on my machine and this worked with an empty local
repository:
mvn clean install -s maven-settings.xml -DskipTests
On Thu, May 22, 2014 at 9:14 AM, Mohan Dhawan
Please open a single JIRA for all of them.
On Tue, May 20, 2014 at 10:29 AM, Emmanuel Bernard
emman...@hibernate.orgwrote:
Hi guys,
I was reading
http://infinispan.org/docs/7.0.x/user_guide/user_guide.html#_jpa_cache_store
I have a few remarks and questions.
The links on 7.3. Additional
On Tue, Jun 3, 2014 at 1:30 PM, Tristan Tarrant ttarr...@redhat.com wrote:
On 03/06/2014 11:35, Sanne Grinovero wrote:
On 3 June 2014 09:57, Mircea Markus mmar...@redhat.com wrote:
On Jun 3, 2014, at 8:53, Tristan Tarrant ttarr...@redhat.com wrote:
Dear all,
on Thursday I issued a PR
disables the bundling for OSGi, so
perhaps a separate profile would be better.
Dan
I'll test your PRs ASAP, thanks a lot.
Cheers,
Sanne
On 9 June 2014 10:19, Dan Berindei dan.berin...@gmail.com wrote:
On Fri, Jun 6, 2014 at 4:31 PM, Sanne Grinovero sa...@infinispan.org
wrote
at this in detail too?
Cheers,
On 09 Jun 2014, at 23:06, Sanne Grinovero sa...@infinispan.org wrote:
On 9 June 2014 14:42, Dan Berindei dan.berin...@gmail.com wrote:
On Mon, Jun 9, 2014 at 12:43 PM, Sanne Grinovero sa...@infinispan.org
wrote:
Hi Dan!
The reason is that I'm making
?focusedCommentId=12970541page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12970541
On 14 May 2014, at 09:36, Dan Berindei dan.berin...@gmail.com wrote:
On Tue, May 13, 2014 at 6:40 PM, Radim Vansa rva...@redhat.com wrote:
On 05/13/2014 03:58 PM, Dan Berindei
On Tue, Jun 24, 2014 at 9:04 PM, William Burns mudokon...@gmail.com wrote:
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
On Thu, Jun 26, 2014 at 6:08 PM, Galder Zamarreño gal...@redhat.com wrote:
I think this is a problem of JDK8, I think I had that before… what JDK are
you using?
On 25 Jun 2014, at 13:08, Wolf-Dieter Fink wf...@redhat.com wrote:
Hi,
I use latest upstream of
On Fri, Jul 4, 2014 at 6:09 PM, Pedro Ruivo pe...@infinispan.org wrote:
Hi guys,
Is there a way to replace the expiryEntryQueue with a non-blocking
structure?
Did you try configuring levelDBStore.expiryQueueSize = MAX_INT?
Long history:
In high throughput systems, this queue gets full
+1 to having a readable (and publicly advertised!) name for our default
JGroups configuration. I particularly like the default-jgroups-tcp.xml
proposal.
We always chastise users for going with their own configuration inherited
from their Infinispan 4.0 days instead of starting with our default
On Tue, Jul 15, 2014 at 5:49 PM, Sanne Grinovero sa...@infinispan.org
wrote:
On 15 July 2014 14:15, Dan Berindei dan.berin...@gmail.com wrote:
On Tue, Jul 15, 2014 at 12:51 AM, Sanne Grinovero sa...@infinispan.org
wrote:
Hi all,
I was toying with a custom CacheStore experiment
1. Configuration inheritance: I would go further and allow the definition
of configurations that cannot be started, only inherited from.
2. Replication queue: I discussed an upgrade to the replication queue with
Will, similar to JGroups' TransferQueuBundler [1]. It does raise an
interesting point
On Mon, Jul 28, 2014 at 7:35 PM, Sanne Grinovero sa...@infinispan.org
wrote:
On 28 July 2014 17:24, Dan Berindei dan.berin...@gmail.com wrote:
1. Configuration inheritance: I would go further and allow the
definition of
configurations that cannot be started, only inherited from.
2
On Wed, Jul 30, 2014 at 12:35 AM, Sanne Grinovero sa...@infinispan.org
wrote:
On 29 July 2014 22:14, Dan Berindei dan.berin...@gmail.com wrote:
On Tue, Jul 29, 2014 at 9:06 PM, Sanne Grinovero sa...@infinispan.org
wrote:
This is a nasty problem and I also feel passionately we need
On Wed, Jul 30, 2014 at 12:00 PM, Pedro Ruivo pe...@infinispan.org wrote:
On 07/30/2014 09:02 AM, Dan Berindei wrote:
if your proposal is only meant to apply to non-tx caches, you are right
you don't have to worry about multiple primary owners... most of the
time. But when
Nice idea! I am using [1] to monitor the PRs I was involved in, which does
a pretty good job, but it's annoying that it misses some updates (like the
build status, most of the time).
I have one suggestion: most PRs are ready for review the moment they are
issued, so I think that should be the
On Wed, Aug 6, 2014 at 6:19 PM, Bela Ban b...@redhat.com wrote:
Hey Dan,
On 06/08/14 16:13, Dan Berindei wrote:
I could create the issue in JIRA, but I wouldn't make it high priority
because I think it have lots of corner cases with NBST and cause
headaches for the maintainers of state
On Tue, Aug 5, 2014 at 11:27 AM, Galder Zamarreño gal...@redhat.com wrote:
Can’t comment on the document, so here are my thoughts:
Re: “Get rid of lazy cache starting...all the caches run on all nodes...it
should still be possible to start a cache at runtime, but it will be run on
all nodes
On Fri, Aug 15, 2014 at 11:37 AM, Galder Zamarreño gal...@redhat.com
wrote:
On 12 Aug 2014, at 22:41, Dan Berindei dan.berin...@gmail.com wrote:
On Tue, Aug 5, 2014 at 11:27 AM, Galder Zamarreño gal...@redhat.com
wrote:
Can’t comment on the document, so here are my thoughts:
Re
It looks to me like you actually want a partial order between caches on
shutdown, so why not declare an explicit dependency (e.g.
manager.stopOrder(before, after)? We could even throw an exception if the
user tries to stop a cache manually in the wrong order (e.g.
TestingUtil.killCacheManagers).
, Sanne Grinovero sa...@infinispan.org wrote:
On 15 August 2014 14:55, Dan Berindei dan.berin...@gmail.com wrote:
It looks to me like you actually want a partial order between caches on
shutdown, so why not declare an explicit dependency (e.g.
manager.stopOrder(before, after)? We could even
On Wed, Aug 20, 2014 at 12:27 PM, Galder Zamarreño gal...@redhat.com
wrote:
On 15 Aug 2014, at 12:41, Dan Berindei dan.berin...@gmail.com wrote:
On Fri, Aug 15, 2014 at 11:37 AM, Galder Zamarreño gal...@redhat.com
wrote:
On 12 Aug 2014, at 22:41, Dan Berindei dan.berin
On Wed, Aug 20, 2014 at 2:32 PM, Sanne Grinovero sa...@infinispan.org
wrote:
On 20 August 2014 11:19, Dan Berindei dan.berin...@gmail.com wrote:
On Wed, Aug 20, 2014 at 1:08 PM, Sanne Grinovero sa...@infinispan.org
wrote:
On 12 August 2014 21:41, Dan Berindei dan.berin...@gmail.com
On Wed, Aug 20, 2014 at 3:40 PM, Radim Vansa rva...@redhat.com wrote:
On 08/20/2014 12:16 PM, Dan Berindei wrote:
On Wed, Aug 20, 2014 at 12:27 PM, Galder Zamarreño gal...@redhat.com
wrote:
On 15 Aug 2014, at 12:41, Dan Berindei dan.berin...@gmail.com wrote:
On Fri, Aug 15
Galder, I think kill is working properly, but the server socket cannot be
bound because a client connection has not finished closing:
http://stackoverflow.com/questions/14388706/socket-options-so-reuseaddr-and-so-reuseport-how-do-they-differ-do-they-mean-t
On Tue, Sep 2, 2014 at 9:09 AM,
Thanks Pedro, this looks great.
However, I don't think it's ok to treat CommitCommands/Pessimistic
PrepareCommands as RemoteLockCommands just because they may send L1
invalidation commands. It's true that those commands will block, but
there's no need to wait for any other command before doing
On Thu, Sep 18, 2014 at 3:29 PM, Pedro Ruivo pe...@infinispan.org wrote:
On 09/18/2014 12:03 PM, Dan Berindei wrote:
Thanks Pedro, this looks great.
However, I don't think it's ok to treat CommitCommands/Pessimistic
PrepareCommands as RemoteLockCommands just because they may send L1
iterator work with invalidation caches?
- Will
On Wed, Oct 8, 2014 at 10:13 AM, Mircea Markus mmar...@redhat.com wrote:
On Oct 8, 2014, at 15:11, Dan Berindei dan.berin...@gmail.com wrote:
On Wed, Oct 8, 2014 at 5:03 PM, Mircea Markus mmar...@redhat.com
wrote:
On Oct 3, 2014, at 9:30
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...@gmail.com
wrote:
So it seems we would want to change this for 7.0 if possible
On Wed, Oct 8, 2014 at 7:53 PM, William Burns mudokon...@gmail.com wrote:
On Wed, Oct 8, 2014 at 12:41 PM, Dan Berindei dan.berin...@gmail.com
wrote:
On Wed, Oct 8, 2014 at 6:19 PM, Radim Vansa rva...@redhat.com wrote:
Users expect that size() will be constant-time (or linear
On Thu, Oct 9, 2014 at 3:40 PM, William Burns mudokon...@gmail.com wrote:
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
On Fri, Oct 10, 2014 at 12:16 AM, Pedro Ruivo pe...@infinispan.org wrote:
On 10/09/2014 04:41 PM, Dan Berindei wrote:
On Thu, Oct 9, 2014 at 3:40 PM, William Burns mudokon...@gmail.com
mailto:mudokon...@gmail.com wrote:
Actually this was something I was hoping to get
Hi Rory
Galder is on PTO for another week, so I'll try to answer instead.
We only use sun.misc.Unsafe directly, in order to implement a variation of
Doug Lea's ConcurrentHashMapV8 that accepts a custom Equivalence
(implementation of equality/hashCode). I guess we'll have to switch to
ongoing transactions and if that is a concern or not.
- Will
On Wed, Oct 8, 2014 at 10:13 AM, Mircea Markus mmar...@redhat.com
wrote:
On Oct 8, 2014, at 15:11, Dan Berindei dan.berin...@gmail.com
wrote:
On Wed, Oct 8, 2014 at 5:03 PM, Mircea Markus mmar...@redhat.com
wrote
wrote:
On Oct 8, 2014, at 15:11, Dan Berindei dan.berin...@gmail.com
wrote:
On Wed, Oct 8, 2014 at 5:03 PM, Mircea Markus mmar...@redhat.com
wrote:
On Oct 3, 2014, at 9:30, Radim Vansa rva...@redhat.com wrote:
Hi,
recently we had a discussion about what size() returns, but I've
On Fri, Oct 10, 2014 at 6:13 PM, Vladimir Blagojevic vblag...@redhat.com
wrote:
On 2014-10-10, 3:03 AM, Dan Berindei wrote:
The problem is that the intermediate keys aren't in the same segment:
we want the reduce phase to access only keys local to the reducing
node, and keys in different
+1
On Fri, Oct 10, 2014 at 11:36 PM, Sanne Grinovero sa...@infinispan.org
wrote:
All,
I occasionally have to hard-reset my whole workspace, delete the
Eclipse projects, and re-import them, especially when I switch between
branches.
I have lots of projects, and they are all nicely grouped
phase.
Cheers
Dan
Emmanuel
On Fri 2014-10-10 10:03, Dan Berindei wrote:
I'd rather not expose this to the user. Instead, we could split the
intermediary values for each key by the source segment, and do the
invalidation of the retried segments in our M/R framework (e.g. when
we
On Fri, Oct 10, 2014 at 8:51 PM, Mircea Markus mmar...@redhat.com wrote:
On Oct 10, 2014, at 15:25, Dan Berindei dan.berin...@gmail.com wrote:
On Fri, Oct 10, 2014 at 5:20 PM, Mircea Markus mmar...@redhat.com
wrote:
On Oct 10, 2014, at 15:18, Radim Vansa rva...@redhat.com wrote
On Fri, Oct 10, 2014 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
On Tue, Oct 14, 2014 at 9:55 AM, Radim Vansa rva...@redhat.com wrote:
On 10/13/2014 05:55 PM, Mircea Markus wrote:
On Oct 13, 2014, at 14:06, Dan Berindei dan.berin...@gmail.com wrote:
On Fri, Oct 10, 2014 at 9:01 PM, Mircea Markus mmar...@redhat.com
wrote:
On Oct 10, 2014, at 17:30
On Wed, Oct 22, 2014 at 10:43 AM, Vojtech Juranek vjura...@redhat.com
wrote:
On Tuesday 21 October 2014 12:46:42 Sanne Grinovero wrote:
I'm sceptical though on embarking into a PR process which assumes that
we're going to be able to keep the testsuite green just because we
decide so; let's
Hi Erik
This makes a lot of sense. In fact, I was really close to implementing it
while I was replacing RebalancePolicy with AvailabilityStrategy.
Unfortunately I hit some problems and I had to postpone it (mostly because
I was also trying to make the flag per-cache).
The only question is what
I don't think we'll ever get to the point where we don't need *any* thread
pools in Infinispan :)
OTOH I also want to reduce the number of thread pools and thread pool
configurations, so I'd rather not add per-cache thread pools until we see a
clear need for it.
In particular, I don't think we
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.
Re: commonPool(), we can (and should) still create our own ForkJoinPool
instead of using the global one.
Cheers
Dan
On Thu,
+1
On Fri, Nov 14, 2014 at 11:49 AM, Pedro Ruivo pe...@infinispan.org wrote:
On 11/14/2014 09:39 AM, Tristan Tarrant wrote:
I have unilaterally decided to bump all schema versions to 7.1. Less
confusing.
+1
Tristan
On 13/11/14 12:06, Tristan Tarrant wrote:
Hi all,
I have
I guess you could say this is a regression, this wouldn't have been
possible when the version was part of the value :)
But I agree an application is very unlikely call replaceWithVersion with
the same value as before, so +1 to document it for now and implement
Hi Radim
First of all, I don't think this is feasible. For example, read-committed
vs repeatable read changes how the entries are stored in the transaction
context, so you can't have a repeatable-read get() in the same transaction
after a read-committed get. Write skew check also requires
Hi Andreas
Have you tried to see much worse your performance is without write-behind?
I wouldn't expect write-behind to help a lot with SingleFileStore
(file-store): since it never calls fsync, writes only go to the OS
write-behind buffers before returning.
Regarding the error per se, I'm afraid
Hi Radim
Please make sure you reply in plain text mode, the replies got a bit mixed up.
On Mon, Nov 24, 2014 at 3:07 PM, Radim Vansa rva...@redhat.com wrote:
On 11/24/2014 12:44 PM, Dan Berindei wrote:
Hi Radim
First of all, I don't think this is feasible. For example, read-committed vs
For people who couldn't attend, the minutes are here:
http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2014/infinispan.2014-11-24-15.02.log.html
Cheers
Dan
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
can only replace based on
values. So I don't think that's a problem.
Tristan
On 26/11/14 16:43, Sanne Grinovero wrote:
On 26 November 2014 at 14:17, Dan Berindei dan.berin...@gmail.com wrote:
Sanne, it will work as long as the previous value is not the same as
the new value.
If multiple
Apparently Hoptimus Prime is no longer brewed...
Cheers
Dan
On Fri, Nov 28, 2014 at 5:18 PM, Tristan Tarrant ttarr...@redhat.com wrote:
Infinispan users and beer lovers,
you can now choose the codename for Infinispan's next release. Head over to:
http://goo.gl/forms/pdERBnVwHD
You have
Hi Radim
I'm afraid the DeltaAware javadoc is quite clear:
* Implementations of DeltaAware automatically gain the ability to perform
fine-grained replication in Infinispan,
* since Infinispan's data container is able to detect these types and only
serialize and transport Deltas around
*
Hi Isaa
We definitely recommend that you try upgrading to 7.0.2.Final, since
we don't support older versions.
That being said, the suspect exceptions and communication timeouts are
a sign of a flaky network, or more likely of excessive garbage
collections. Have you tried enabling GC logging to
JR, could you share your test, or at least the configuration you used
and what key/value types you used?
Like Radim said, in your 1+0 scenario with storeAsBinary disabled and
no cache store attached, I would expect the latency to be exactly the
same for all value sizes.
Cheers
Dan
On Mon, Dec
On Tue, Dec 23, 2014 at 9:39 PM, Sanne Grinovero sa...@infinispan.org wrote:
That's great, thanks a lot to Dan for writing it.
But it's a very long document, and how would you all prefer to handle
feedback, challenges and improvement proposals?
I think the best option is to clone the wiki
Adrian, I don't think that will work. The Hash doesn't know the number of
segments so it can't tell where a particular key will land - even assuming
knowledge about how the ConsistentHash will map hash codes to segments.
However, I'm all for replacing the current Hash interface with another
Couldn't WildFly and the CDI provider both set a different
globalJmxStatistics().cacheManagerName() for the cache managers they create?
Cheers
Dan
On Thu, Jan 22, 2015 at 10:52 AM, Sebastian Łaskawiec slask...@redhat.com
wrote:
Hey!
When I was moving CDI quickstart to a new repository (from
at least 3 places in code where it happens, so it is time to
document it or move this responsibility to the Hash interface as you
suggest
to make it really pluggable.
Adrian
On 01/20/2015 03:32 PM, Dan Berindei wrote:
Adrian, I don't think that will work. The Hash doesn't know
No, we do not guarantee that an entry will not be lost. When the split
happens, either one partition could end up with 0 owners for a particular
segment, and it will allocate new owners for that segment. When the merge
happens, that partition's consistent hash may be chosen as the merge
consistent
Nothing to do here, the user answered the question himself :)
Dan
On Mon, Feb 16, 2015 at 1:06 PM, Manik Surtani ma...@infinispan.org wrote:
On 13 February 2015 at 05:35, Tomas Sykora tsyk...@redhat.com wrote:
One last note -- actually the thing that there is so many new SO
questions is
deployment information, so we can't use deployment name for that
purpose). Nevertheless I think that situation would be perfectly
acceptable.
Thanks
Sebastian
On 01/22/2015 10:41 AM, Dan Berindei wrote:
Couldn't WildFly and the CDI provider both set a different
globalJmxStatistics
as a node has loaded
all entries from disk, new entries are added to this node with high
frequency (several thousand/s).
The other nodes might not be up yet. It takes 'forever' to bring them up
then...?
On 02/03/2015 12:32 PM, Dan Berindei wrote:
Hi Andreas
Yes, that's the one. 1200s
Hi Galder
Using cache.putAsync on the server will use a thread from the async
transport executor. While the default number of threads in the
transport executor is higher (25), it's still going to be exhausted at
some point as you're generating more and more duplicate operations
from the client.
401 - 500 of 666 matches
Mail list logo
