IgnoreExtraResponsesValidityFilter
by Manik Surtani
Looking at IgnoreExtraResponsesValidityFilter - this seems to be a scalability issue! It seems to copy a set of every address in the cluster and gradually remove entries as responses come in. Isn't this a scalability issue? Since - assuming a large cluster - for every prepare command, we create a collection, copy into it the entire list of addresses (think hundreds of nodes x hundreds of concurrent threads) only to "count down" on the responses. I'm almost certain there is a better way to do this! :) Maybe even maintain a shared list of members (updated whenever there is a view change) to test for responses from non-members, a counter, and assume that members don't respond to the same request more than once?
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
14 years, 1 month
5.0 to 5.1 upgrade gotchas
by Galder Zamarreño
Hi all,
We need to document a list of gotcha's related to 5.0 to 5.1 upgrades as we prepare for final. So far I have noted these myself:
- wakeUpInterval now defined only via expiration (XSD allowds wakeUpInterval in eviction but new parser does not) and not via eviction.
- maxEntries is the strict max but this is likely to not be reached since eviction happens per segment
- transactional vs non-transactional caches, mixed cases not allowed
If you can think of more, reply back and we can compile them in time.
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
14 years, 1 month
5.1 documentation
by Galder Zamarreño
Hi all,
With final just around the corner, could individual owners of articles in https://docs.jboss.org/author/display/ISPN check that they content up to date information?
Please remember that we know have old versions of documentation (i.e. https://docs.jboss.org/author/display/ISPN50/Home), so the documentation should really contain latest info.
I think it's Ok though to mention that this or that change is active since version x.y.z, but anything else should be left to old docs.
Thanks in advance!
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
14 years, 1 month
TransactionTable concurrent maps and concurrency levels
by Manik Surtani
The two concurrent maps (for local and remote transactions) use default concurrency levels. Should these be tuneable in <transaction …>, and either way, what should they default to? I really don't think the JDK default (16!) is nearly good enough. I have a benchmark that runs 250 threads and this causes a lot of blocking on these maps.
How about <locking concurrencyLevel … > as the default for these maps? Is that good enough in terms of a config parameter, or do we want finer-grained control?
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
14 years, 1 month
GitHub's "assign to" drop down on pull requests
by Manik Surtani
This is new on GitHub. I think it is a great way to pick someone specific to review a pull request. :) I suggest leaving it blank if you don't care who reviews the request, or specify someone if you want a particular person to take a look.
I think it is also useful as a mechanism to "acquire a lock" on the pull request, so that someone doesn't inadvertently merge in a request while another reviewer is still testing it out. :)
Thoughts?
Manik
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
14 years, 1 month
Global configuration consistency issue
by Galder Zamarreño
Hi Pete,
I've found a consistency issue in the global configuration:
TransportConfiguration has a reference to Transport coming from transportClass attribute resolution.
However, when you go to SerializationConfiguration, you see Class<? extends Marshaller> rather than Marshaller as resolved from marshallerClass. I think this should Marshaller as opposed to Class<? extends Marshaller>. WDYT?
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
14 years, 1 month
Distribution across multiple sites
by Bela Ban
Tobias made me aware of a bug that can happen when we use RELAY and one
of the relay coordinators crash: messages sent between the crash of the
relay coordinator and the switch of the backup relay to full relay are
not relayed.
This can lead to inconsistencies, see [1] for details. If I implement
solution #1, then the chances of this happening are vastly reduced.
I wanted to ask the bright folks on this list though, if you see a
solution that only involves Infinispan (rebalancing) ?
Cheers,
[1] https://issues.jboss.org/browse/JGRP-1401
--
Bela Ban
Lead JGroups (http://www.jgroups.org)
JBoss / Red Hat
14 years, 1 month
Infinispan 5.1.0.CR3 release
by Tristan Tarrant
Dear all,
as you all know 5.1.0.CR2 failed inclusion in AS7 7.1.0.CR1 because of
ISPN-1644 [1]. Brian Stansberry is asking to reopen the pull request I
initially opened [2] with an appropriate release. Since we now have
regular CI builds of both AS7 and Infinispan master snapshots (thanks to
our great QE team) we can now be a bit more prompt in fixing these
problems before it's too late. To remain in a spirit of promptness, I
would recommend getting a CR3 (and possibly further CRs) out as quickly
as possible to expedite integration and testing. I know a release
requires a bit of effort (especially on Galder's part, and I'm willing
to help here if necessary), but I believe both code-bases would benefit
greatly.
What do you all think ?
Tristan
[1] https://issues.jboss.org/browse/ISPN-1644
[2] https://github.com/jbossas/jboss-as/pull/981#issuecomment-3344718
14 years, 2 months
Transactions and using synchronizations instead of XA - and ISPN-1284
by Manik Surtani
After spending some hours on ISPN-1284, I think we have a few conceptual problems with using Synchronizations.
Here is the topic branch containing my work:
https://github.com/maniksurtani/infinispan/tree/t_1284
So far what I have done is:
* Changed defaults
* Changed config validations to emit a warning and disable synchronisations if recovery is enabled
* Update some tests that rely on XA to specifically set synchronisations to false
But there are still some issues, and what specifically worry me is behaviour demonstrated by these two test failures:
testModsCommit(org.infinispan.lock.StaleEagerLocksOnPrepareFailureTest)
testNoModsCommit(org.infinispan.lock.StaleEagerLocksOnPrepareFailureTest)
They both attempt to abort a transaction by throwing an exception during prepare. Now since we use Synchronizations by default, these failures do *not* abort the transaction since it is only seen by the SynchronizationAdapter in afterCommit(). Where does this stand, conceptually? With optimistic transactions, locks may not be able to be acquired at prepare-time. These transactions should fail.
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
14 years, 2 months
