June 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3959) JdbcBinaryStore's expiration locks buckets indefinitely

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3959?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3959: ----------------------------------- Affects Version/s: 7.0.0.Alpha4 6.0.2.Final > JdbcBinaryStore's expiration locks buckets indefinitely > ------------------------------------------------------- > > Key: ISPN-3959 > URL: https://issues.jboss.org/browse/ISPN-3959 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.2.Final, 7.0.0.Alpha4 > Reporter: Radim Vansa > Assignee: Radim Vansa > Fix For: 7.0.0.Alpha5 > > > The buckets are locked in eviction thread (in the main purge method), while unlocked in BucketPurger.call() which is executed in persistence thread. The unlock fails and the buckets stay locked indefinitely. > Another error is that the Bucket class is not serializable. > This is also a bug in BaseStoreTest as this uses WithinThreadExecutor as the executor for purging while usually this is done in different thread. Moreover, as the purge method is actually not obliged to purge anything, the test does not test the purging itself, but rather a check for expired entry when it is loaded (contains operation). The purging should be enforced by purge listener (calling the purge method until all entries are purged). -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3959) JdbcBinaryStore's expiration locks buckets indefinitely

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3959?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3959: ----------------------------------- Assignee: Radim Vansa (was: Mircea Markus) > JdbcBinaryStore's expiration locks buckets indefinitely > ------------------------------------------------------- > > Key: ISPN-3959 > URL: https://issues.jboss.org/browse/ISPN-3959 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Radim Vansa > Assignee: Radim Vansa > > The buckets are locked in eviction thread (in the main purge method), while unlocked in BucketPurger.call() which is executed in persistence thread. The unlock fails and the buckets stay locked indefinitely. > Another error is that the Bucket class is not serializable. > This is also a bug in BaseStoreTest as this uses WithinThreadExecutor as the executor for purging while usually this is done in different thread. Moreover, as the purge method is actually not obliged to purge anything, the test does not test the purging itself, but rather a check for expired entry when it is loaded (contains operation). The purging should be enforced by purge listener (calling the purge method until all entries are purged). -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4400) Initial state transfer with large number of segments is very slow

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4400?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4400: ------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.0.0.Alpha5 Resolution: Done > Initial state transfer with large number of segments is very slow > ----------------------------------------------------------------- > > Key: ISPN-4400 > URL: https://issues.jboss.org/browse/ISPN-4400 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core, State Transfer > Affects Versions: 7.0.0.Alpha4 > Reporter: Tristan Tarrant > Assignee: Adrian Nistor > Fix For: 7.0.0.Alpha5, 7.0.0.Final > > > StateTransfer performance is O(n²) based on the number of segments -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4448) RHQ server plugin: synchronize data operation String casting to Byte array fails

by Tomas Sykora (JIRA)

[ https://issues.jboss.org/browse/ISPN-4448?page=com.atlassian.jira.plugin.... ] Tomas Sykora commented on ISPN-4448: ------------------------------------ Now we lost our old ispn-cli.sh where it was possible to call upgrade command with parameters. I am not aware of any way how I can call Synchronize Data command using CLI in the newest server. Is there such a possibility? > RHQ server plugin: synchronize data operation String casting to Byte array fails > -------------------------------------------------------------------------------- > > Key: ISPN-4448 > URL: https://issues.jboss.org/browse/ISPN-4448 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JMX, reporting and management > Affects Versions: 7.0.0.Alpha4 > Reporter: Tomas Sykora > Assignee: William Burns > Labels: rhq > > Invocation of rolling upgrades related operation -- Synchronize Data -- on a new node's cache fails with a following error: > java.lang.Exception: JBAS011002: Failed to invoke operation: java.lang.String cannot be cast to [B, rolled-back=true > at org.rhq.core.pc.operation.OperationInvocation.run(OperationInvocation.java:278) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > Note, that there is also ISPN-4447 which says, that we can't record known global keyset using RHQ. > In this issue, we proceed that operation using CLI interface console in order to create dumped keys. Then, we tried to synchronize data using RHQ cache operation and passing "hotrod" as a migrator. This was expected to work properly. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4426) Transaction replayed but not committed

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4426?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4426: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2677 > Transaction replayed but not committed > -------------------------------------- > > Key: ISPN-4426 > URL: https://issues.jboss.org/browse/ISPN-4426 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: State Transfer > Affects Versions: 7.0.0.Alpha4 > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > Labels: 63gablocker > > Dist TX cache, node C is joining. In previous topology, entry is owned by A (primary) and B (backup). In new topology, primary ownership is transferred to C, B stays backup. > 1. TX is prepared in old topology and is being committed, when topology changes > 2. on C (the new owner), the TX info is received and later even the old entry > 3. C receives the CommitCommand, therefore, it correctly replays the PrepareCommand. > 4. When the entries are about to be committed, in TxInterceptor the transaction is found to be already completed as it has lower TxID. > Result: the transaction is not being executed and stale data stay on the node (with my algortihm it eventually led to complete entry loss). -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3480) Use protoparser lib instead of relying on binary descriptors generated by protoc

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-3480?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes commented on ISPN-3480: ----------------------------------------- Can protostream be released with the latest changes? > Use protoparser lib instead of relying on binary descriptors generated by protoc > -------------------------------------------------------------------------------- > > Key: ISPN-3480 > URL: https://issues.jboss.org/browse/ISPN-3480 > Project: Infinispan > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Marshalling > Affects Versions: 6.0.0.Alpha4 > Reporter: Adrian Nistor > Assignee: Gustavo Fernandes > Labels: 64QueryBlockers > Fix For: 7.0.0.Beta1 > > > Use protoparser [1] for obtaining type metadata rather than relying one the binary descriptors generated by Google Prootbuf's protoc tool. > [1] https://github.com/square/protoparser -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3718) Select which protobuf fields to index

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-3718?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes commented on ISPN-3718: ----------------------------------------- The new protoparser embedded in the protostream library can retain comments at runtime, so something like this would be possible: {code} message User { //... /* @Indexed(Analyzer=StandardAnalyzer) */ required string name = 3 //... } {code} > Select which protobuf fields to index > ------------------------------------- > > Key: ISPN-3718 > URL: https://issues.jboss.org/browse/ISPN-3718 > Project: Infinispan > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Embedded Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: 64QueryBlockers > > Currently we index all fields. An interesting idea is to use a custom protobuf Option (see 'Custom Options' section here https://developers.google.com/protocol-buffers/docs/proto) to indicate which message types and specifically which fields should be indexed, similar to Hibernate Search annotations. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3480) Use protoparser lib instead of relying on binary descriptors generated by protoc

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3480?page=com.atlassian.jira.plugin.... ] Adrian Nistor commented on ISPN-3480: ------------------------------------- The changes on the protostream side are now integrated: https://github.com/infinispan/protostream/pull/4. Updating infinispan is next. > Use protoparser lib instead of relying on binary descriptors generated by protoc > -------------------------------------------------------------------------------- > > Key: ISPN-3480 > URL: https://issues.jboss.org/browse/ISPN-3480 > Project: Infinispan > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Marshalling > Affects Versions: 6.0.0.Alpha4 > Reporter: Adrian Nistor > Assignee: Gustavo Fernandes > Labels: 64QueryBlockers > Fix For: 7.0.0.Beta1 > > > Use protoparser [1] for obtaining type metadata rather than relying one the binary descriptors generated by Google Prootbuf's protoc tool. > [1] https://github.com/square/protoparser -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3160) RemoteCacheManager javadocs list wrong default pool size

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3160?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-3160: ---------------------------------------- Tristan, pull request was closed. Can you send a new one with this minor fix? > RemoteCacheManager javadocs list wrong default pool size > -------------------------------------------------------- > > Key: ISPN-3160 > URL: https://issues.jboss.org/browse/ISPN-3160 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Remote Protocols > Affects Versions: 5.1.8.Final > Reporter: Dennis Reed > Assignee: Tristan Tarrant > Priority: Minor > Fix For: 7.0.0.Alpha5 > > > RemoteCacheManager javadocs list the default pool size as 10: > "infinispan.client.hotrod.default_executor_factory.pool_size, default = 10." > However, the default is actually 99: > org/infinispan/client/hotrodimpl/ConfigurationProperties.java: return props.getIntProperty(DEFAULT_EXECUTOR_FACTORY_POOL_SIZE, 99); -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3160) RemoteCacheManager javadocs list wrong default pool size

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3160?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3160: ----------------------------------- Fix Version/s: 7.0.0.Alpha5 > RemoteCacheManager javadocs list wrong default pool size > -------------------------------------------------------- > > Key: ISPN-3160 > URL: https://issues.jboss.org/browse/ISPN-3160 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Remote Protocols > Affects Versions: 5.1.8.Final > Reporter: Dennis Reed > Assignee: Tristan Tarrant > Priority: Minor > Fix For: 7.0.0.Alpha5 > > > RemoteCacheManager javadocs list the default pool size as 10: > "infinispan.client.hotrod.default_executor_factory.pool_size, default = 10." > However, the default is actually 99: > org/infinispan/client/hotrodimpl/ConfigurationProperties.java: return props.getIntProperty(DEFAULT_EXECUTOR_FACTORY_POOL_SIZE, 99); -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2014