November 2013 - infinispan-issues

[JBoss JIRA] (ISPN-3675) Revisit covariant return type for various implementations

by William Burns (JIRA)

William Burns created ISPN-3675: ----------------------------------- Summary: Revisit covariant return type for various implementations Key: ISPN-3675 URL: https://issues.jboss.org/browse/ISPN-3675 Project: Infinispan Issue Type: Enhancement Affects Versions: 6.0.0.CR1 Reporter: William Burns Assignee: Mircea Markus We use interfaces all over the place, which is great. However a lot of implementations currently only define their return types to be that of the type defined in the interface. However we can change the implementation return type of the method to be covariant which allows for direct users of the implementation to use the subclass if desired. This especially came up in the discussion here: https://github.com/infinispan/infinispan/pull/2177/files#r7375883 as we could remove redundant casts which would provide cleaner code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3400) Upgrade to JCache 1.0.0-PFD

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3400?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3400: ----------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2187 > Upgrade to JCache 1.0.0-PFD > --------------------------- > > Key: ISPN-3400 > URL: https://issues.jboss.org/browse/ISPN-3400 > Project: Infinispan > Issue Type: Component Upgrade > Components: JCache > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 6.0.0.CR2, 6.0.0.Final > > > JCache 1.0.0-PFD represents the Final Draft version of JSR-107. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3589) StackOverflow in InternalMetadataImpl.Externalizer

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3589?page=com.atlassian.jira.plugin.... ] Pedro Ruivo commented on ISPN-3589: ----------------------------------- [~mircea.markus] you don't mind if I solve this right? :) > StackOverflow in InternalMetadataImpl.Externalizer > -------------------------------------------------- > > Key: ISPN-3589 > URL: https://issues.jboss.org/browse/ISPN-3589 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.CR1 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Labels: 620 > Fix For: 6.0.0.CR2 > > > the implementation delegates to another metadata some methods. The result is a chain of InternalMetadataImpl as you can see in: > {code} > metadata=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=Inte > rnalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl > {actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=Internal > MetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{act > ual=InternalMetadataImpl [....] > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3589) StackOverflow in InternalMetadataImpl.Externalizer

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3589?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3589: ------------------------------ Fix Version/s: 6.0.0.CR2 > StackOverflow in InternalMetadataImpl.Externalizer > -------------------------------------------------- > > Key: ISPN-3589 > URL: https://issues.jboss.org/browse/ISPN-3589 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.CR1 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Labels: 620 > Fix For: 6.0.0.CR2 > > > the implementation delegates to another metadata some methods. The result is a chain of InternalMetadataImpl as you can see in: > {code} > metadata=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=Inte > rnalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl > {actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=Internal > MetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{act > ual=InternalMetadataImpl [....] > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3589) StackOverflow in InternalMetadataImpl.Externalizer

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3589?page=com.atlassian.jira.plugin.... ] Pedro Ruivo reassigned ISPN-3589: --------------------------------- Assignee: Pedro Ruivo (was: Mircea Markus) > StackOverflow in InternalMetadataImpl.Externalizer > -------------------------------------------------- > > Key: ISPN-3589 > URL: https://issues.jboss.org/browse/ISPN-3589 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.CR1 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Labels: 620 > > the implementation delegates to another metadata some methods. The result is a chain of InternalMetadataImpl as you can see in: > {code} > metadata=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=Inte > rnalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl > {actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=Internal > MetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{act > ual=InternalMetadataImpl [....] > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3589) StackOverflow in InternalMetadataImpl.Externalizer

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3589?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3589: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2186 > StackOverflow in InternalMetadataImpl.Externalizer > -------------------------------------------------- > > Key: ISPN-3589 > URL: https://issues.jboss.org/browse/ISPN-3589 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.CR1 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Labels: 620 > > the implementation delegates to another metadata some methods. The result is a chain of InternalMetadataImpl as you can see in: > {code} > metadata=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=Inte > rnalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl > {actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=Internal > MetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{actual=InternalMetadataImpl{act > ual=InternalMetadataImpl [....] > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3665) SingleFileStore is not thread-safe for passivation

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/ISPN-3665?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on ISPN-3665: ------------------------------------ Ah - interesting. I'm no FileChannel expert, so it appears I made a number of incorrect assumptions. I'm going to close that quick and dirty PR in favor of a proper fix. > SingleFileStore is not thread-safe for passivation > -------------------------------------------------- > > Key: ISPN-3665 > URL: https://issues.jboss.org/browse/ISPN-3665 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 6.0.0.CR1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Blocker > Labels: 620 > Attachments: Test.java > > > SingleFileStore never makes use of FileChannel.force(...) to flush changes to disk. This causes problems for the passivation use case. > If one thread evicts a cache entry, while immediately after another thread attempts to read the same cache entry, the Cache.get(...) can return null. This is because the entry is never flushed to disk. > I've attached a test to reproduce the problem. > I also ran the same test with the addition of FileChannel.force(false) to the write(...) method, and the test succeeds. > A proper fix should probably make this a configurable property (as it was with the old file store implementation). It would be nice if the flush could defer until just before tx commit, but, off hand, I don't know how feasible that is. > I suspect this lack of flush also accounts for much of the bold claim of a 100x performance improvement over the old file store implementation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3665) SingleFileStore is not thread-safe for passivation

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/ISPN-3665?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated ISPN-3665: ------------------------------- Status: Open (was: Pull Request Sent) Git Pull Request: (was: https://github.com/infinispan/infinispan/pull/2180) > SingleFileStore is not thread-safe for passivation > -------------------------------------------------- > > Key: ISPN-3665 > URL: https://issues.jboss.org/browse/ISPN-3665 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 6.0.0.CR1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Blocker > Labels: 620 > Attachments: Test.java > > > SingleFileStore never makes use of FileChannel.force(...) to flush changes to disk. This causes problems for the passivation use case. > If one thread evicts a cache entry, while immediately after another thread attempts to read the same cache entry, the Cache.get(...) can return null. This is because the entry is never flushed to disk. > I've attached a test to reproduce the problem. > I also ran the same test with the addition of FileChannel.force(false) to the write(...) method, and the test succeeds. > A proper fix should probably make this a configurable property (as it was with the old file store implementation). It would be nice if the flush could defer until just before tx commit, but, off hand, I don't know how feasible that is. > I suspect this lack of flush also accounts for much of the bold claim of a 100x performance improvement over the old file store implementation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3665) SingleFileStore is not thread-safe for passivation

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/ISPN-3665?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated ISPN-3665: ------------------------------- Assignee: Mircea Markus (was: Paul Ferraro) > SingleFileStore is not thread-safe for passivation > -------------------------------------------------- > > Key: ISPN-3665 > URL: https://issues.jboss.org/browse/ISPN-3665 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 6.0.0.CR1 > Reporter: Paul Ferraro > Assignee: Mircea Markus > Priority: Blocker > Labels: 620 > Attachments: Test.java > > > SingleFileStore never makes use of FileChannel.force(...) to flush changes to disk. This causes problems for the passivation use case. > If one thread evicts a cache entry, while immediately after another thread attempts to read the same cache entry, the Cache.get(...) can return null. This is because the entry is never flushed to disk. > I've attached a test to reproduce the problem. > I also ran the same test with the addition of FileChannel.force(false) to the write(...) method, and the test succeeds. > A proper fix should probably make this a configurable property (as it was with the old file store implementation). It would be nice if the flush could defer until just before tx commit, but, off hand, I don't know how feasible that is. > I suspect this lack of flush also accounts for much of the bold claim of a 100x performance improvement over the old file store implementation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3617) Inconsistent L1 in non-tx distributed cache

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3617?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3617: ----------------------------------------------- Radim Vansa <rvansa(a)redhat.com> changed the Status of [bug 1017796|https://bugzilla.redhat.com/show_bug.cgi?id=1017796] from ON_QA to VERIFIED > Inconsistent L1 in non-tx distributed cache > ------------------------------------------- > > Key: ISPN-3617 > URL: https://issues.jboss.org/browse/ISPN-3617 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.2.7.Final > Reporter: Radim Vansa > Assignee: William Burns > Priority: Critical > Labels: 620 > Fix For: 6.0.0.CR2, 6.0.0.Final > > > When the change is replicated to backup owner, it sends the InvalidateL1Command to backup owners before committing the entry in EntryWrappingInterceptor (it performs the WriteCommand in parallel with sending the invalidation commmand, but then it waits until the invalidation request gets acked. If a GET is executed between the invalidation and committing the entry, the response contains outdated result and the L1 will not be invalidated until next write operation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2013