Fwd: [JBoss JIRA] (ISPN-1629) REST server test suite should use 5.1 namespace
by Tristan Tarrant
Pete, since the introduction of the Stax parser, the REST test suite was
failing because it could not parse the 5.0 namespace. I solved it by
changing it, but I was wondering whether we should also be able to parse
5.0 configuration files, since we're in the same major version ?
Tristan
-------- Original Message --------
Subject: [JBoss JIRA] (ISPN-1629) REST server test suite should use 5.1
namespace
Date: Tue, 20 Dec 2011 03:21:09 -0500 (EST)
From: Tristan Tarrant (Created) (JIRA) <jira-events(a)lists.jboss.org>
To: ttarrant(a)redhat.com
REST server test suite should use 5.1 namespace
-----------------------------------------------
Key: ISPN-1629
URL: https://issues.jboss.org/browse/ISPN-1629
Project: Infinispan
Issue Type: Bug
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
Since the introduction of the new Stax parser, the REST tests are failing because the config xml uses the 5.0 namespace.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
logger and ineritance
by Mircea Markus
Re: your first point here: http://bit.ly/tl2q14
With this approach not only that an additional method call is added (hardly a big performance fault, but still..) but for me it makes it harder to compare the logs with the code, as the class that contains the code might be different than the class that "runs" the code.
In my case at least, it's important to be able to compare the logs with the code fast - as this is the way I use the logs.
OTOH I agree that the logs don't tell you straight away the runtime class where the code was ran - but TBH I don't remember that being an issue for me. I remember though being annoyed by "overridden" loggers in a previous project - hence my email :-)
I'd be very curios hear other opinion on this, especially Galder's as I imagine he did a fare share of log reading back in the days.
Cheers,
Mircea
14 years
PutForExternalRead performance in 5.1
by Galder Zamarreño
Hi,
Re: https://issues.jboss.org/browse/ISPN-1615, https://issues.jboss.org/browse/ISPN-1617 and http://lists.jboss.org/pipermail/infinispan-dev/2011-November/009577.html
I think in Infinispan 5.1, the fact that caches are either transaction or not transactional are affecting the functionality and performance of operations such as putForExternalRead().
The point of PFER is to make data available to other nodes and transactions which has just been read from the database, without blocking, ignoring failures…etc.
This operation makes most sense when autoCommit is false and there's an external transaction going on, i.e. Hibernate 2LC. As shown in ISPN-1617, this does not work (Note: currently I have 2LC set to autoCommit=true to make this work but it's not performant as indicated by Slorg1).
So, to make this work, we can do three things:
1. As Mircea suggested, we could start a new transaction for PFER after suspending the on-going one. Apart from this being wasteful (suspend and start a new tx) it's pointless because pFER is FORCE_ASYNCHRONOUS operation, so we're ignoring any failures in other nodes to apply the data.
2. Another option is to avoid suspending the transaction. Ever since https://issues.jboss.org/browse/ISPN-1556 was implemented, a failure within a transaction when FAIL_SILENT is on won't rollback the tx. Not suspending the tx has the advantage of not being wasteful from a tx management perspective. The problem though is that PFER won't be applied until the external tx has been commited, so it delays this operation. On top of this, I have the feeling that if the cache is configured with SYNC, this PFER might be become 2PC (mircea, can you clarify?)
3. The third and final option is to basically allow PFER to act as non-transactional even if the cache is transactional so that the transaction can be suspended and PFER can do its job as quick as possible (like it did in 5.0 and before). We know PFER is an special operation with particular options, can't we make room for this non-transactional op? This seems to me the best middle ground between a PFER that does its job and it's performant. I've implemented this in https://github.com/galderz/infinispan/commit/d10fee9b2800d752695059530440... and both the newly created test and PutForExternalReadTest pass at least (the rest of testsuite needs checking). Mircea, WDYT?
WDYT?
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
14 years
FYI: IntelliJ 11 and TestNG
by Manik Surtani
Something fishy with IntelliJ 11 which has had me chasing my tail for a while now - when running TestNG tests from the IDE, the JVM IntelliJ launches does *not* have the -ea flag on (previous versions did!) This means that assertions that fail *don't* cause a test to fail, giving you false positives.
To fix this, I added -ea to the default set of VM options when running TestNG tests.
Note that running tests via Maven are not affected and in fact this is how I spotted the issue.
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
14 years
benchmarking 5.1 vs 5.0
by Mircea Markus
Hi,
Now that all the 5.1 major work is done I plan to run some benchmarks comparing 5.1 with 5.0. It's not only tx stuff I'd like to compare, as some other were made, so here's my plan of action.
Each of the following benchmarks will be run on local, distributed and replicated caches:
1. non transactional: web session replication[1]
2. transactional (both optimistic and pessimistic): web session replication[2]
3. transactional (both optimistic and pessimistic): tpcc [3]
The difference between 2 and 3 is the fact that 3 induces some key contention between transactions.
Any other suggestion for benchmarking?
Cheers,
Mircea
[1] http://sourceforge.net/apps/trac/radargun/wiki/WebSessionBenchmark
[2] http://sourceforge.net/apps/trac/radargun/wiki/BenchmarkingTransactions
[3] tpcc is Radargun extension developed by Sebastiano Peluso from the CloudTM team. It's now integrated in Radargun, I'm working on adding some documentation around it atm.
14 years
boolean properties in config
by Pete Muir
https://issues.jboss.org/browse/ISPN-1474
Currently we do a mix of:
enableXXX()
disableXXX()
enabled(boolean b)
XXX(boolean b)
where XXX is something to enable or disable (e.g. purgeOnStartup). We also the scatter the word use around in a very inconsistent fashion.
I would like to rationalise this, and would propose that every boolean has:
enableXXX
disableXXX
xxxEnabled(boolean b)
The former 2 are nice for hardcoded config, the latter is nice when you are adapting one format to another (e.g. Paul).
I would deprecate the usage of XXX(boolean b) and useXXX(boolean b) and remove in 6.
Thoughts?
14 years
