On Mon, May 13, 2013 at 8:44 PM, Sanne Grinovero sa...@infinispan.orgwrote:
On 13 May 2013 18:32, Manik Surtani msurt...@redhat.com wrote:
On 13 May 2013, at 16:25, Mircea Markus mmar...@redhat.com wrote:
On 13 May 2013, at 15:05, Manik Surtani wrote:
100% agree, most users will
Mircea, I think I'm missing something here. Why would the originator send a
TxCompletionNotificationCommand at all if the commit command was
asynchronous?
I don't think recovery should require the originator to send a
TxCompletionNotificationCommand. Our commit commands can't fail anyway, so
the
Hi guys
I'm working on an intermittent failure in NodeMoveAPIPessimisticTest and I
think I've come across what I think is underspecified behaviour in
AtomicHashMap.
Say we have two transactions, tx1 and tx2, and they both work with the same
atomic map in a pessimistic cache:
1. tx1: am1 =
On Fri, May 17, 2013 at 1:59 PM, Mircea Markus mmar...@redhat.com wrote:
On 17 May 2013, at 07:35, Dan Berindei dan.berin...@gmail.com wrote:
On Thu, May 16, 2013 at 8:27 PM, Mircea Markus mmar...@redhat.com
wrote:
On 16 May 2013, at 15:04, Dan Berindei dan.berin...@gmail.com
On Mon, May 20, 2013 at 1:57 PM, Manik Surtani msurt...@redhat.com wrote:
On 16 May 2013, at 15:04, Dan Berindei dan.berin...@gmail.com wrote:
Hi guys
I'm working on an intermittent failure in NodeMoveAPIPessimisticTest and I
think I've come across what I think is underspecified behaviour
I wouldn't want to deprecate CCL, I think it definitely has a purpose - at
least in invalidation mode.
Even in replication mode, having a lazy alternative to state transfer may
be useful. Maybe not for the topology cache, but it might make sense for
large caches.
On Tue, May 21, 2013 at 4:36
I guess the grouper could use a KeyAffinityService (or something similar)
to generate a key local to each node and return that instead of 0 or 1.
However, you won't have any guarantee that the keys will stay on the same
node if the cache topology changes (e.g. another node joins).
It used to be
Oracle will support Java 7 at least until March 2015 [1]. And it's very
likely that some people will keep using 7 after that, just like they are
using 6 now. So unless we want to support Java 6 until 2016, I don't think
we can skip 7.
[1] http://www.oracle.com/technetwork/java/eol-135779.html
* ForkJoinPool (assuming we can get AS to inject one)
* AutoCloseable
* Throwable.addSuppressed()
On Fri, May 24, 2013 at 2:01 AM, Mircea Markus mmar...@redhat.com wrote:
Sent from my iPhone
On 23 May 2013, at 12:06, Bela Ban b...@redhat.com wrote:
On 5/23/13 12:38 PM, Manik
On Wed, May 29, 2013 at 4:50 PM, Pedro Ruivo pe...@infinispan.org wrote:
Hi all,
//related to https://issues.jboss.org/browse/ISPN-3100
In here [1] I've added three simple tests to the CARD logic with the
ResponseFilter.
#1 testResponses() = tests if all the responses are returned. This
If we only want to deal with full cluster shutdown, then I think stopping
all application requests, calling Cache.clear() on one node, and then
shutting down all the nodes should be simpler. On start, assuming no cache
store, the caches will start empty, so starting all the nodes at once and
only
Hi guys
CacheLoaderInterceptor and DistributionInterceptor both honour the
IGNORE_RETURN_VALUES flag for get commands, but I think it would be more
useful if they ignored it - just like they ignore it for conditional
commands.
That would make it possible for users to only keep a reference to a
...@infinispan.orgwrote:
Hi Dan,
I'm not sure I understood this. How can I prevent it to return values
if you have the flag ignored? Note that in some cases it makes a huge
performance difference.
Sanne
On 3 June 2013 10:52, Dan Berindei dan.berin...@gmail.com wrote:
Hi guys
CacheLoaderInterceptor
are confusing and ideally we should evolve the API, as the JSR
did, or push on The Jokre.
On 3 Jun 2013 11:08, Dan Berindei dan.berin...@gmail.com wrote:
Sanne, I'm only talking about get operations. I was thinking that if you
call cache.get(key), you want the value of that key, regardless
Fair point... ok, let's leave it as it is now.
On Mon, Jun 3, 2013 at 5:23 PM, Galder Zamarreño gal...@redhat.com wrote:
On Jun 3, 2013, at 11:52 AM, Dan Berindei dan.berin...@gmail.com wrote:
Hi guys
CacheLoaderInterceptor and DistributionInterceptor both honour
There's a link 'Login as guest' at the bottom of the login form at
ci.infinispan.org, you can use that and you'll see all the builds. You can
also create a user for yourself.
On Mon, Jun 3, 2013 at 6:01 PM, Guillaume SCHEIBEL
guillaume.schei...@gmail.com wrote:
I don't think I have access to
On Tue, Jun 4, 2013 at 12:27 PM, Mircea Markus mmar...@redhat.com wrote:
On 3 Jun 2013, at 19:01, Dan Berindei dan.berin...@gmail.com wrote:
Fair point... ok, let's leave it as it is now.
On Mon, Jun 3, 2013 at 5:23 PM, Galder Zamarreño gal...@redhat.com
wrote:
On Jun 3, 2013
On Mon, Jun 3, 2013 at 4:23 PM, vitalii.tymchys...@ubs.com wrote:
Hello.
Thanks for your information. I will subscribe and vote for the issues
noted.
In the meantime I've implemented hacky JgroupsTransport that downgrades
all (but CacheViewControlCommand and StateTransferControlCommand)
).
Best regards, Vitalii Tymchyshyn
--
*From:* infinispan-dev-boun...@lists.jboss.org [mailto:
infinispan-dev-boun...@lists.jboss.org] *On Behalf Of *Dan Berindei
*Sent:* Wednesday, June 05, 2013 12:04 PM
*To:* infinispan -Dev List
*Subject:* Re: [infinispan-dev
On Thu, Jun 6, 2013 at 9:08 PM, Ray Tsang saturn...@gmail.com wrote:
On Jun 6, 2013, at 13:26, Mircea Markus mmar...@redhat.com wrote:
On 4 Jun 2013, at 13:55, Dan Berindei dan.berin...@gmail.com wrote:
CacheLoaderInterceptor and DistributionInterceptor both honour
Yes, putAll is really heavy in non-tx (concurrent) mode, because the same
PutMapCommand is forwarded from each primary owner to all the backup owners
of the keys it primary-owns. However, I don't think
However, in non-tx mode locks are owned by threads. A separate lock command
would acquire a
On Tue, Jun 11, 2013 at 2:01 PM, Manik Surtani msurt...@redhat.com wrote:
On 10 Jun 2013, at 15:12, Dan Berindei dan.berin...@gmail.com wrote:
Erik, I think in your case you'd be better served by a
ConsistentHashFactory that always assigns at most one owner from each
machine for each
On Wed, Jun 12, 2013 at 2:57 PM, Manik Surtani msurt...@redhat.com wrote:
On 11 Jun 2013, at 16:27, Dan Berindei dan.berin...@gmail.com wrote:
On Tue, Jun 11, 2013 at 2:01 PM, Manik Surtani msurt...@redhat.comwrote:
On 10 Jun 2013, at 15:12, Dan Berindei dan.berin...@gmail.com wrote
On Wed, Jun 12, 2013 at 5:39 PM, Radim Vansa rva...@redhat.com wrote:
- Original Message -
| From: Bela Ban b...@redhat.com
| To: infinispan-dev@lists.jboss.org
| Sent: Wednesday, June 12, 2013 3:16:58 PM
| Subject: Re: [infinispan-dev] New bundler performance
|
|
|
| On
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:
Maybe we could just clarify the javadoc of IGNORE_RETURN_VALUES and say
Done: https://github.com/infinispan/infinispan/pull/1900
On Thu, Jun 13, 2013 at 4:15 PM, Mircea Markus mmar...@redhat.com wrote:
Hi Dan,
snip
But unfortunately the partial shutdown case does NOT work, if the
coordinator node is a member of partial shutdown nodes.
When the coordinator is
Ben, I'm pretty sure it's not possible to define getKeyForAddress as
returning the same type as its input key.
Let's say f1(address)(x) = getKeyForAddress(address, x)
f1(address) has to be injective for each address. So if the size of the key
domain is size(K) and the number of addresses is N,
On Fri, Jun 14, 2013 at 5:46 PM, cotton-ben
ben.cot...@alumni.rutgers.eduwrote:
/It's probably possible to define something like this instead:
PinnedKeyK getKeyForAddress(address, key)
/
This is fine. Do it this way.
/Even so, keeping the result key pinned to the same address after a
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 TxDistributionInterceptor and I have a couple of
questions (assuming
On Mon, Jun 17, 2013 at 7:00 PM, Mircea Markus mmar...@redhat.com wrote:
On 17 Jun 2013, at 16:11, Dan Berindei dan.berin...@gmail.com wrote:
I think that, given that the local node is not owner, the lock
acquisition is redundant even for pessimistic caches.
Mind creating a test
On Mon, Jun 17, 2013 at 6:35 PM, William Burns mudokon...@gmail.com wrote:
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.orgwrote:
On 06/17/2013 12:56 PM, Mircea Markus wrote:
On 17 Jun
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
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
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
tuned!
Cheers,
Dan Berindei
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
-1 as well, as a user you only use ConfigurationBuilder and
GlobalConfigurationBuilder directly, and moving them to a subpackage would
make them less accessible.
If anything, I'd move these two classes to the parent package
(org.infinispan.configuration), but like Sanne said there's no point in
On Thu, Jun 27, 2013 at 2:52 PM, Galder Zamarreño gal...@redhat.com wrote:
On Jun 27, 2013, at 12:09 PM, Manik Surtani msurt...@redhat.com wrote:
On 27 Jun 2013, at 09:57, Galder Zamarreño gal...@redhat.com wrote:
On Jun 26, 2013, at 12:28 PM, Dan Berindei dan.berin...@gmail.com
On Thu, Jun 27, 2013 at 4:18 PM, 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 caches. Async caches with L1 have
their own issues as well, but I
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 (preferably for both non-tx and tx cases) and send an
email to the list?
And
natural
- I meant to comment on your proposal in one email and to describe my
alternative proposal in the second email.
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 apologize
On Fri, Jun 28, 2013 at 12:51 AM, William Burns mudokon...@gmail.comwrote:
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
On Fri, Jun 28, 2013 at 3:41 PM, William Burns mudokon...@gmail.com wrote:
On Fri, Jun 28, 2013 at 5:53 AM, Dan Berindei dan.berin...@gmail.com
wrote:
On Fri, Jun 28, 2013 at 12:51 AM, William Burns mudokon...@gmail.com
wrote:
On Thu, Jun 27, 2013 at 4:40 PM, Dan Berindei dan.berin
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...@gmail.com
wrote:
Trying to leave my points that would most likely have
On Tue, Jul 2, 2013 at 5:59 PM, Pedro Ruivo pe...@infinispan.org wrote:
Hi all,
simple question: What are the consistency guaranties that is supposed to
be ensured?
I have the following scenario (happened in a test case):
NonOwner: remote get key
BackupOwner: receives the remote get and
On Tue, Jul 2, 2013 at 6:36 PM, Pedro Ruivo pe...@infinispan.org wrote:
On 07/02/2013 04:21 PM, Sanne Grinovero wrote:
+1 for considering it a BUG
Didn't we decide a year ago that GET operations should be sent to a
single node only (the primary) ?
+1 :)
Manik had a patch for
On Tue, Jul 2, 2013 at 6:35 PM, Pedro Ruivo pe...@infinispan.org wrote:
On 07/02/2013 04:29 PM, Dan Berindei wrote:
On Tue, Jul 2, 2013 at 5:59 PM, Pedro Ruivo pe...@infinispan.org
mailto:pe...@infinispan.org wrote:
Hi all,
simple question: What are the consistency
It's not wrong, sending the invalidation only from the primary owner is
wrong :)
On Tue, Jul 2, 2013 at 7:14 PM, Sanne Grinovero sa...@infinispan.orgwrote:
I see, so we keep the wrong implementation because it's faster?
:D
On 2 July 2013 16:38, Dan Berindei dan.berin...@gmail.com wrote
On Tue, Jul 2, 2013 at 8:41 PM, Sanne Grinovero sa...@infinispan.orgwrote:
On 2 July 2013 17:24, Dan Berindei dan.berin...@gmail.com wrote:
It's not wrong, sending the invalidation only from the primary owner is
wrong :)
Agreed, sending a GET operation to multiple nodes might not be wrong
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
mailto:pe...@infinispan.org wrote:
On 07/02/2013 04:29 PM, Dan Berindei wrote
On Mon, Jul 8, 2013 at 12:19 AM, Sanne Grinovero sa...@infinispan.orgwrote:
On 3 July 2013 10:26, Dan Berindei dan.berin...@gmail.com wrote:
On Tue, Jul 2, 2013 at 8:41 PM, Sanne Grinovero sa...@infinispan.org
wrote:
On 2 July 2013 17:24, Dan Berindei dan.berin...@gmail.com wrote
Pedro, I'll integrate the PR as it is, and then you can experiment with my
proposal in another branch/PR.
On Tue, Jul 9, 2013 at 1:48 PM, Pedro Ruivo pe...@infinispan.org wrote:
On 07/09/2013 11:46 AM, Galder Zamarreño wrote:
On Jul 8, 2013, at 11:02 AM, Pedro Ruivo pe...@infinispan.org
Do we need to change something in pom.xml as well so that it's included
automatically in the next release?
On Mon, Jul 8, 2013 at 10:30 PM, Mircea Markus mmar...@redhat.com wrote:
Thanks for updating the release doc :-)
On 5 Jul 2013, at 10:02, Tristan Tarrant ttarr...@redhat.com wrote:
On Tue, Jul 9, 2013 at 12:48 PM, Mircea Markus mmar...@redhat.com wrote:
On 21 May 2013, at 17:09, Dan Berindei dan.berin...@gmail.com wrote:
I wouldn't want to deprecate CCL, I think it definitely has a purpose -
at least in invalidation mode.
The only use case I'm aware
Dear Infinispan community,
We're proud to announce the second Alpha release of Infinispan 6.0.0, and
also the second release using the Apache Software Licence.
New features in this release:
- A new query DSL https://issues.jboss.org/browse/ISPN-3169 that is
usable both in embedded/library
+1 to make it per loader
On Thu, Aug 8, 2013 at 6:30 PM, Galder Zamarreño gal...@redhat.com wrote:
On Aug 8, 2013, at 11:43 AM, Mircea Markus mmar...@redhat.com wrote:
Currently the shared attribute is configured at *loaders* level, so
all the defined cache loaders inherit this attribute.
Are you using explicit transactions or only implicit transactions?
As of 5.2, non-transactional caches use a scheme where the modification is
sent to the primary owner, which then sends the modification to the backup
owner(s). The primary owner waits for responses from all the backup owners,
and
Hi guys
As you know, I'm working on ISPN-3051, allowing each node to take a higher
or lower proportion of the entries in the cache. I've implemented this by
adding a float loadFactor setting in each node's configuration, with 1
being the default and any positive value being accepted (including
On Mon, Sep 9, 2013 at 12:34 PM, Tristan Tarrant ttarr...@redhat.comwrote:
On 09/09/2013 11:18 AM, Dan Berindei wrote:
Hi guys
As you know, I'm working on ISPN-3051, allowing each node to take a
higher or lower proportion of the entries in the cache. I've
implemented this by adding
On Wed, Oct 2, 2013 at 12:48 PM, Pedro Ruivo pe...@infinispan.org wrote:
On 10/02/2013 12:03 AM, Sanne Grinovero wrote:
I'd love to brainstorm about the clear() operation and what it means
on Infinispan.
I'm not sure to what extent, but it seems that clear() is designed to
work in a
+1 to apply it, but maybe we should use the occasion to move the error
message to the Log interface as well.
On Fri, Oct 4, 2013 at 2:43 AM, Sanne Grinovero sa...@infinispan.orgwrote:
Currently if a cache is configured with indexing enabled, but the
Query module isn't on classpath, you get a
On Thu, Oct 3, 2013 at 1:57 PM, Sanne Grinovero sa...@infinispan.orgwrote:
On 3 October 2013 10:29, Dan Berindei dan.berin...@gmail.com wrote:
On Wed, Oct 2, 2013 at 12:48 PM, Pedro Ruivo pe...@infinispan.org
wrote:
On 10/02/2013 12:03 AM, Sanne Grinovero wrote:
I'd love
every commit.
On Mon, Oct 7, 2013 at 4:09 PM, Sanne Grinovero sa...@infinispan.orgwrote:
Nice!
Is that going to work out with our hardware?
We'll need to be careful now with the configured duration of each such
test.
On 7 October 2013 13:48, Dan Berindei dan.berin...@gmail.com wrote:
I've
I've seen StateTransferLargeObjectTest hang on my machine with all OOB
threads waiting in FlowControl$Credit.decrementIfEnoughCredits, but I
thought that was because the JGroups internal thread pool wasn't enabled in
the test configuration. Now that I've seen it's enabled by default, I think
it
I changed the default config some time ago, but I forgot to close ISPN-3334.
On Fri, Oct 11, 2013 at 4:35 PM, Ray Tsang saturn...@gmail.com wrote:
also, don't forget this one: https://issues.jboss.org/browse/ISPN-3334
On Fri, Oct 11, 2013 at 9:22 AM, Erik Salter an1...@hotmail.com wrote:
Bela, do you really need to rename the thread? You already pass a name
argument to the Thread constructor, why not create the thread with the
correct name directly?
On Thu, Oct 17, 2013 at 5:48 PM, Dennis Reed der...@redhat.com wrote:
On 10/17/2013 05:26 AM, Bela Ban wrote:
The other thing
On Tue, Oct 29, 2013 at 1:33 PM, Pedro Ruivo pe...@infinispan.org wrote:
On 10/29/2013 07:58 AM, Radim Vansa wrote:
On 10/25/2013 08:17 PM, Pedro Ruivo wrote:
Hi guys.
I've open a JIRA to tack this:
https://issues.jboss.org/browse/ISPN-3664
Suggestions/feedback is appreciated.
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 this,
but I can't seem to locate it now. I was hoping to get to it next
release.
On Mon, Nov 18, 2013 at 9:43 AM, Galder Zamarreño gal...@redhat.com wrote:
On Nov 14, 2013, at 1:20 PM, Pedro Ruivo pe...@infinispan.org wrote:
Hi,
Simple question: shouldn't PFER ensure some consistency?
I know that PFER is asynchronous but (IMO) it can create inconsistencies
in
I have already issued a PR for NonTxStateTransferOverwritingValue2Test:
https://github.com/infinispan/infinispan/pull/2228
On Mon, Nov 18, 2013 at 10:13 PM, Mircea Markus mmar...@redhat.com wrote:
Your machines are notorious the high number of intermittent failures, so
this doesn't look that
Mircea, what exactly are the problems that we want to achieve by moving
everything back in a single repository?
To me, the biggest problem right now is that builds take way too long, and
if I integrate something in master it will take almost an entire day for
TeamCity to update the status on all
On Tue, Nov 19, 2013 at 11:21 AM, Martin Gencur mgen...@redhat.com wrote:
On 19.11.2013 09:59, Dan Berindei wrote:
BTW, Maven rebuilds every module in the reactor every time you run a
build. On my machine, it takes 6 minutes to build everything in the
Infinispan reactor. Would you really
, but there may be plenty of other things that could
fail without the caller knowing. So the question remains, should give up on
synchronizations (except maybe with asynchronous commit/1PC, if we decide
to keep that)?
On Tue, Nov 19, 2013 at 6:01 PM, Dan Berindei dan.berin...@gmail.comwrote:
Maybe
When it comes to IDEs, I'd rather remove some more modules from the main
project in order to make it more responsive and easier to use. Launching a
test from IntelliJ takes minutes to build (or parse, or analyze, or
whatever) everything, when it works. Extra dependencies on old versions in
the
Sorry Sanne for ignoring your message, I meant to send the reply to Manik's
:)
I agree that depending on SNAPSHOTS from another repository is not a good
idea. After all, we couldn't even make the dependencies work in CI for the
jobs we have now - the REST cache store's build still fails because
Yes, it was implemented in Beta1:
http://blog.infinispan.org/2013/09/heterogenous-clusters-with-infinispan.html
Cheers
Dan
On Wed, Nov 20, 2013 at 11:37 AM, Radim Vansa rva...@redhat.com wrote:
Hi, the heterogenous clusters link does not work. I also miss any
related JIRA in release notes -
On Thu, Nov 21, 2013 at 5:39 PM, Pedro Ruivo pe...@infinispan.org wrote:
On 11/21/2013 03:18 PM, Dan Berindei wrote:
Hmm, couldn't you just disable recovery in the TM to get the same
performance with a XA resource as with a synchronization?
If you are suggesting to mess around
On Thu, Nov 21, 2013 at 12:35 PM, Galder Zamarreño gal...@redhat.comwrote:
On Nov 18, 2013, at 12:42 PM, Dan Berindei dan.berin...@gmail.com wrote:
On Mon, Nov 18, 2013 at 9:43 AM, Galder Zamarreño gal...@redhat.com
wrote:
On Nov 14, 2013, at 1:20 PM, Pedro Ruivo pe
Hmm, couldn't you just disable recovery in the TM to get the same
performance with a XA resource as with a synchronization?
On Thu, Nov 21, 2013 at 1:57 PM, Pedro Ruivo pe...@infinispan.org wrote:
On 11/21/2013 11:34 AM, Galder Zamarreño wrote:
It's way faster actually. The speed
On Thu, Nov 21, 2013 at 1:55 PM, Galder Zamarreño gal...@redhat.com wrote:
On Nov 20, 2013, at 11:03 AM, Dan Berindei dan.berin...@gmail.com wrote:
When it comes to IDEs, I'd rather remove some more modules from the main
project in order to make it more responsive and easier to use
).
- Will
On Thu, Nov 21, 2013 at 9:54 AM, Dan Berindei dan.berin...@gmail.com
wrote:
On Thu, Nov 21, 2013 at 12:35 PM, Galder Zamarreño gal...@redhat.com
wrote:
On Nov 18, 2013, at 12:42 PM, Dan Berindei dan.berin...@gmail.com
wrote:
On Mon, Nov 18, 2013 at 9:43 AM
On Fri, Nov 22, 2013 at 10:26 AM, Radim Vansa rva...@redhat.com wrote:
On 11/21/2013 05:09 PM, Dan Berindei wrote:
On Thu, Nov 21, 2013 at 5:39 PM, Pedro Ruivo pe...@infinispan.org wrote:
On 11/21/2013 03:18 PM, Dan Berindei wrote:
Hmm, couldn't you just disable recovery in the TM
suggested would also address my
concern, but at the expense of extra misses from the cache - especially in
DIST mode. Hence my proposal to not support PFER in DIST mode at all.
On Fri, Nov 22, 2013 at 3:45 PM, Dan Berindei dan.berin...@gmail.comwrote:
That doesn't sound right, we don't keep any
On Fri, Nov 22, 2013 at 6:15 PM, Pedro Ruivo pe...@infinispan.org wrote:
On 11/22/2013 11:40 AM, Sanne Grinovero wrote:
Do we still need to support the non-V8 implementations?
Clearly there are cases in which we need it to be available:
On Wed, Nov 27, 2013 at 10:15 AM, Galder Zamarreño gal...@redhat.comwrote:
On Nov 22, 2013, at 12:31 PM, Pedro Ruivo pe...@infinispan.org wrote:
On 11/21/2013 10:08 PM, Sanne Grinovero wrote:
Hi Pedro,
great analysis.
Conceptually I agree, and since I'm not too familiar with the
On Mon, Dec 2, 2013 at 11:44 AM, Galder Zamarreño gal...@redhat.com wrote:
On Nov 27, 2013, at 3:06 PM, Mircea Markus mmar...@redhat.com wrote:
- how does the server know that a request originated from a certain
client in order not to send it to that client again? There's no clientId in
Hi Radim
Actually, it's me that wrote the denormalization code :)
It was meant as a stop-gap measure before we upgraded the HotRod protocol
to support the segment-based consistent hash, but the denormalization
worked well enough (or so we thought) that we didn't get to changing the
protocol yet.
/2013 09:18 AM, Dan Berindei wrote:
Hi Radim
Actually, it's me that wrote the denormalization code :)
It was meant as a stop-gap measure before we upgraded the HotRod protocol
to support the segment-based consistent hash, but the denormalization
worked well enough (or so we thought) that we
On Wed, Dec 11, 2013 at 11:37 AM, Radim Vansa rva...@redhat.com wrote:
On Wed, Dec 11, 2013 at 10:38 AM, Radim Vansa rva...@redhat.com wrote:
Hi Dan
I am not speaking about changing something for the C++ client, I
understand that the client code cannot be changed in order to keep the
On Thu, Dec 12, 2013 at 12:52 AM, David M. Lloyd david.ll...@redhat.comwrote:
On 12/11/2013 04:47 PM, Pedro Ruivo wrote:
Hi,
I've created a method to clean a specific ThreadLocal variable from all
live threads [1].
My goal is to clean the ThreadLocal variables after a cache stops.
On Thu, Dec 19, 2013 at 2:15 PM, Emmanuel Bernard emman...@hibernate.orgwrote:
On Thu 2013-12-19 9:46, Galder Zamarreño wrote:
== Example of continuous query atop remote listeners
Thinking about how to implement continuous query atop this
infrastructure I am missing a few things.
On Thu, Dec 19, 2013 at 8:43 PM, Emmanuel Bernard emman...@hibernate.orgwrote:
On Thu 2013-12-19 19:57, Dan Berindei wrote:
On Thu, Dec 19, 2013 at 2:15 PM, Emmanuel Bernard
emman...@hibernate.orgwrote:
On Thu 2013-12-19 9:46, Galder Zamarreño wrote:
== Example of continuous query
On Fri, Dec 13, 2013 at 4:11 PM, Radim Vansa rva...@redhat.com wrote:
On 12/13/2013 02:44 PM, Galder Zamarreño wrote:
On Dec 6, 2013, at 10:45 AM, Radim Vansa rva...@redhat.com wrote:
Hi,
1) IMO, filtering for specific key is a very important use case.
Registering a filterId is a very
On Fri, Dec 20, 2013 at 12:20 PM, Emmanuel Bernard
emman...@hibernate.orgwrote:
On Fri 2013-12-20 12:09, Dan Berindei wrote:
On Thu, Dec 19, 2013 at 8:43 PM, Emmanuel Bernard
emman...@hibernate.orgwrote:
On Thu 2013-12-19 19:57, Dan Berindei wrote:
On Thu, Dec 19, 2013 at 2:15 PM
On Tue, Jan 7, 2014 at 9:14 PM, Brett Meyer brme...@redhat.com wrote:
Apologies for the delay -- things have been nuts.
Here's the route I've taken so far. I created OsgiClassLoader that
searches available Bundles for classes and resources. A new (non-static)
AggregateClassLoader replaces
On Tue, Jan 21, 2014 at 4:07 PM, Mircea Markus mmar...@redhat.com wrote:
Hi Emmanuel,
Just had a good chat with Davide on this and one solution to overcome the
shortcoming you mentioned in the above email would be to enhance the hotrod
client to support grouping:
RemoteClient.put(G g, K k,
On 22 Jan 2014 16:10, Pedro Ruivo pe...@infinispan.org wrote:
On 01/22/2014 01:58 PM, Dan Berindei wrote:
It would also require us to keep a SetK for each group, with the keys
associated with that group. As such, I'm not sure it would be a lot
easier to implement (correctly) than
I think it's way too early to discuss removing FineGrainedAtomicMap and
AtomicMap, as long as we don't have a concrete alternative with similar
properties.
Cache.getGroup(groupName) is just a method name at this point, we don't
have any idea how it will compare to AtomicMap/FineGrainedAtomicMap
...@infinispan.org wrote:
On 01/27/2014 09:20 AM, Sanne Grinovero wrote:
On 23 January 2014 18:03, Dan Berindei dan.berin...@gmail.com
wrote:
On 22 Jan 2014 16:10, Pedro Ruivo pe...@infinispan.org wrote:
On 01/22/2014 01:58 PM, Dan Berindei wrote:
It would also require us
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 benefit of L1OnRehash
especially compared to the benefits it provide.
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 is
doing builds.
These logs are retrieved from [1].
Dunno how our CI is configured but this is odd. Seems like the build is
halt due to test
301 - 400 of 666 matches
Mail list logo
