JIRA priorities
by Mircea Markus
I'd like a way to see what are the JIRAs that are absolutely critical for a release (i.e. won't release without them in) and the ones that won't delay the release, but would be rolled over to next release.
I'm thinking to mark these JIRAs as:
- Critical if they must make it for the Final
- Blocker if they must make it for the next release (might be an Alpha)
What do people think?
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
14 years
ISPN-2314 fix looks fishy
by Galder Zamarreño
Hi guys,
Having briefly investigated https://issues.jboss.org/browse/ISPN-2314, I consider the fix (https://github.com/infinispan/infinispan/pull/1318) to be rather fishy.
Sure it works, but it masks the fact that the order in which things are started has changed (This IMO seems to be the result of http://issues.jboss.org/browse/ISPN-2256).
Not only that, but the fact that you have to modify both the component registry and the configuration makes me think that there're situations where the configuration changes are applied, and others where it's not (hence why you have to change the component registry).
So, can we please stop and try to understand what really is happening here? I was expecting Mircea to have a look into a fix for this since it looks related to cache start order.
Personally, I don't really see why the lifecycle manager has to mess up with the component registry. Changes to the configuration were 'enough' (until 2256) and I don't see why that should change.
Cheers,
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
14 years
BUILD FAILURE
by Sanne Grinovero
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile
(default-compile) on project infinispan-core: Compilation failure
[ERROR] /home/sanne/pb/infinispan/core/src/main/java/org/infinispan/xsite/BackupReceiverRepositoryImpl.java:[59,70]
cannot find symbol
[ERROR] symbol : method getSiteName(short)
[ERROR] location: class org.jgroups.protocols.relay.SiteUUID
Thanks,
your personal Jenkins
14 years
Re: [infinispan-dev] Issue with cache blocks for local read-only cache
by Manik Surtani
Agreed.
This locking appears to be in the 2LC integration code to guard a local collection though - there must be better, non-blocking ways to guard this - if it is needed at all for RO entities.
- M
On 18 Sep 2012, at 15:18, Andrig Miller <anmiller(a)redhat.com> wrote:
> What I find interesting, is that in this use case, READ_ONLY concurrency strategy and a local cache (no invalidation and no replication), there is no need to do any locking.
>
> If we can get to a solution without any locking that would be ideal.
>
> Andy
>
> From: "Manik Surtani" <manik(a)jboss.org>
> To: "Ståle W. Pedersen" <spederse(a)redhat.com>
> Cc: "Galder Zamarreño" <galder(a)redhat.com>, "John O'Hara" <johara(a)redhat.com>, "Jeremy Whiting" <jwhiting(a)redhat.com>, "Andrig Miller" <anmiller(a)redhat.com>, "Steve Ebersole" <steve(a)hibernate.org>, "infinispan-dev" <infinispan-dev(a)lists.jboss.org>
> Sent: Tuesday, September 18, 2012 8:13:43 AM
> Subject: Re: Issue with cache blocks for local read-only cache
>
> Looking at your profiler snapshot, these locks are in the Hibernate 2nd level cache implementation for Infinispan. Galder, any ideas?
>
> - M
>
> On 18 Sep 2012, at 13:43, Ståle W. Pedersen <spederse(a)redhat.com> wrote:
>
> hi galder and manik, sorry for sending this mail to so many, but we've ran into a issue that prevents us from further scaling of the specjenterprise2010 benchmark.
>
> so when doing specjenterprise2010 benchmark testing we've seen a lot of blocks caused by the entity/query cache. we've been testing with only caching a simple entity bean that's read-only and queries related to this entity (selects).
>
> here is a screenshot of the hotspot found:https://dl.dropbox.com/u/30971563/specjent_block.png
>
> here is the standalone.xml: https://dl.dropbox.com/u/30971563/standalone-full.xml
>
> here is the orm.xml: https://dl.dropbox.com/u/30971563/order_orm.xml
>
> what we don't understand is why there are so many puts into the cache for an object that is marked as read-only. when we're testing without caching we do not see any blocks.
>
> any help/ideas would be great. if anyone want a jprofiler snapshot of the run, let me know.
>
> regards, ståle
> --
> JBoss Performance Team Lead
> JBoss by Red Hat
>
> --
> Manik Surtani
> manik(a)jboss.org
> twitter.com/maniksurtani
>
> Platform Architect, JBoss Data Grid
> http://red.ht/data-grid
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Platform Architect, JBoss Data Grid
http://red.ht/data-grid
14 years
ISPN-2296 Query projections
by Marko Lukša
Hey Sanne and others,
before I send a pull request, can you review my impl of ISPN-2296 at
https://github.com/luksa/infinispan/compare/ISPN-2296. I'd like your
input on this before implementing this on clustered queries.
Basically here's what I did:
Extracted an interface (QueryResultLoader - any ideas for a better
name?) from EntityLoader and introduced ProjectionLoader. This took care
of projection of actual fields.
For projecting the cache key, I introduced ProjectionConverter, which
translates the fields passed to cacheQuery.projection(fields) into
fields that hsearch can deal with (currently, only
ispn.ProjectionConstants.KEY is replaced with
hsearch.ProjectionConstants.ID). The converter is then also used to
convert the actual values returned by hsearch (for
cacheQuery.projection(ProjectionConstants.KEY), it converts the id
returned by hsearch into the cache key).
Just for completeness, besides introducing ispn.PC.KEY, I also added
PC.VALUE, which is equivalent to hsearch.PC.THIS.
Marko
14 years
X-Site: Site Unreachable vs. Site Down
by Erik Salter
Hi all,
For the X-Site pull request, Bela, Mircea and I had a design review. One of
the items that came up was the ability to mark a site as being down
where a site has been unreachable for a period of time. This mostly applies
to the synchronous replication case where the backup failure policy has been
configured as FAIL, i.e:
<namedCache name="importantCache">
<sites>
<backups>
<backup site="NYC" strategy="SYNC" backupFailurePolicy="FAIL" timeout="16000
0"/>
</backups>
</sites>
</namedCache>
The current implementation would be to fail all requests until a SA realizes
the site is offline and mark it through a JMX operation (provided in this
release?). Since I cannot afford a 100% failure rate until somebody gets
called, I think we need to take it a step further and add an element to mark
a site as offline after a period of time. (Note, though, a site can only
be brought back online manually.)
Mircea talked about adding an element in the configuration for a custom
callback implementation. However, I think this is useful enough -- not only
for me -- but for other ISPN/JDG users as well. (Not to mention we can't
add configuration for callbacks)
Comments?
Thanks,
Erik
14 years
