December 2012 - infinispan-issues

[JBoss JIRA] (ISPN-2293) New async store implementation with stress test

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2293?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2293: ----------------------------------------------- Martin Gencur <mgencur(a)redhat.com> made a comment on [bug 862594|https://bugzilla.redhat.com/show_bug.cgi?id=862594] I'm changing the target milestone to ER6 because the bug verification is blocked by another bug targeted for ER6. > New async store implementation with stress test > ----------------------------------------------- > > Key: ISPN-2293 > URL: https://issues.jboss.org/browse/ISPN-2293 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 5.2.0.Beta1 > > > Encompasses work related to Karsten's new async store implementation, adding further functional tests related to ISPN-1174, and add an async store stress test. -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-1174) Using an AsyncStore with eviction creates a time window in which entries might not be found

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-1174?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-1174: ----------------------------------------------- Martin Gencur <mgencur(a)redhat.com> made a comment on [bug 862594|https://bugzilla.redhat.com/show_bug.cgi?id=862594] I'm changing the target milestone to ER6 because the bug verification is blocked by another bug targeted for ER6. > Using an AsyncStore with eviction creates a time window in which entries might not be found > ------------------------------------------------------------------------------------------- > > Key: ISPN-1174 > URL: https://issues.jboss.org/browse/ISPN-1174 > Project: Infinispan > Issue Type: Bug > Components: Eviction, Loaders and Stores, Locking and Concurrency > Affects Versions: 5.0.0.CR5 > Reporter: Sanne Grinovero > Assignee: Galder Zamarreño > Priority: Blocker > Labels: async, write_behind > Fix For: 5.2.0.Alpha4, 5.2.0.Final > > > When loading from an AsyncStore we should check if the entry is not in process of being written to the underlying store (somewhere in the async queue), as at this point it was already removed from the container and if not yet written on the store it might not be found otherwise. > See also http://infinispan.markmail.org/search/#query:%20from%3A%22Manik%20Surtani... -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2625) Verify Cross-site transfer performace

by Radim Vansa (JIRA)

Radim Vansa created ISPN-2625: --------------------------------- Summary: Verify Cross-site transfer performace Key: ISPN-2625 URL: https://issues.jboss.org/browse/ISPN-2625 Project: Infinispan Issue Type: Task Components: Cross-Site Replication Affects Versions: 5.2.0.Beta5 Reporter: Radim Vansa Assignee: Mircea Markus Attachments: jgroups-lon-nyc-sfo-belaban.xml, jgroups-site.xml, lon-tx-optimistic-xs-to-nyc-async.xml, nyc-tx-optimistic-xs-from-lon.xml The performance of asynchronous cross-site transfer is questionable. In QA lab we got 2x-4x slower reads (GET) than in no-XS scenario and write (PUT) performance equivalent to those of synchronous XS. While the code cannot be reliably profiled with instrumentation, trace logs also radically slow down the test we have not identified any particular bug that should cause this issue. Therefore, I'd like to ask someone from the core developers to try to reproduce such test results and provide his test description together with achieved results. We have used three-node cluster in distributed mode with optimistic transactions, replicating to another three-node cluster with the same configuration. Physically the nodes were in the same cluster without any delay element. The logical clusters used different multicast addresses in their JGroups configuration. Each node started 10 threads which issued PUT/GET requests in a loop with 1:4 ratio. Each request was wrapped in single transaction. The test was benchmarking the average duration of each operation during 10 minute period preceded by 3 minute warmup with identical configuration but not accounted into performance results. JGroups configurations as well as Infinispan configuration will be enclosed. -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2625) Verify Cross-site transfer performace

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-2625?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-2625: ------------------------------ Attachment: jgroups-lon-nyc-sfo-belaban.xml jgroups-site.xml lon-tx-optimistic-xs-to-nyc-async.xml nyc-tx-optimistic-xs-from-lon.xml > Verify Cross-site transfer performace > ------------------------------------- > > Key: ISPN-2625 > URL: https://issues.jboss.org/browse/ISPN-2625 > Project: Infinispan > Issue Type: Task > Components: Cross-Site Replication > Affects Versions: 5.2.0.Beta5 > Reporter: Radim Vansa > Assignee: Mircea Markus > Attachments: jgroups-lon-nyc-sfo-belaban.xml, jgroups-site.xml, lon-tx-optimistic-xs-to-nyc-async.xml, nyc-tx-optimistic-xs-from-lon.xml > > > The performance of asynchronous cross-site transfer is questionable. In QA lab we got 2x-4x slower reads (GET) than in no-XS scenario and write (PUT) performance equivalent to those of synchronous XS. While the code cannot be reliably profiled with instrumentation, trace logs also radically slow down the test we have not identified any particular bug that should cause this issue. > Therefore, I'd like to ask someone from the core developers to try to reproduce such test results and provide his test description together with achieved results. > We have used three-node cluster in distributed mode with optimistic transactions, replicating to another three-node cluster with the same configuration. Physically the nodes were in the same cluster without any delay element. The logical clusters used different multicast addresses in their JGroups configuration. > Each node started 10 threads which issued PUT/GET requests in a loop with 1:4 ratio. Each request was wrapped in single transaction. The test was benchmarking the average duration of each operation during 10 minute period preceded by 3 minute warmup with identical configuration but not accounted into performance results. > JGroups configurations as well as Infinispan configuration will be enclosed. -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2564) Send distributed tasks to cache members rather than the entire cluster

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2564?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-2564: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.2.0.Beta6 (was: 5.2.0.Final) (was: 5.2.0.CR1) Resolution: Done Integrated. Vladimir, could you link here the issue for the other places where we should use RpcManager.getMembers() instead of Transport.getMembers()? > Send distributed tasks to cache members rather than the entire cluster > ---------------------------------------------------------------------- > > Key: ISPN-2564 > URL: https://issues.jboss.org/browse/ISPN-2564 > Project: Infinispan > Issue Type: Bug > Components: Core API > Affects Versions: 5.2.0.Beta4 > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Fix For: 5.2.0.Beta6 > > > Currently our codebase relies on the cache views to be equal to entire cluster, however, this might not be the case due to asymmetric cluster; certain cache instances running only on particular Infinispan nodes. We have to make sure that cache views, if needed are scoped properly to particular cache rather than entire cluster -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2564) Send distributed tasks to cache members rather than the entire cluster

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2564?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-2564: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/1522 > Send distributed tasks to cache members rather than the entire cluster > ---------------------------------------------------------------------- > > Key: ISPN-2564 > URL: https://issues.jboss.org/browse/ISPN-2564 > Project: Infinispan > Issue Type: Bug > Components: Core API > Affects Versions: 5.2.0.Beta4 > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Fix For: 5.2.0.CR1, 5.2.0.Final > > > Currently our codebase relies on the cache views to be equal to entire cluster, however, this might not be the case due to asymmetric cluster; certain cache instances running only on particular Infinispan nodes. We have to make sure that cache views, if needed are scoped properly to particular cache rather than entire cluster -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2624) JDG: Storage-only example: HotRodDecoder: NSEE: key not found: node1/clustered

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2624?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-2624: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=875151 > JDG: Storage-only example: HotRodDecoder: NSEE: key not found: node1/clustered > ------------------------------------------------------------------------------ > > Key: ISPN-2624 > URL: https://issues.jboss.org/browse/ISPN-2624 > Project: Infinispan > Issue Type: Bug > Reporter: Tomas Sykora > Assignee: Mircea Markus > > This is issue to distinguish from https://issues.jboss.org/browse/ISPN-2550. > For logs and more info see related BZ: https://bugzilla.redhat.com/show_bug.cgi?id=875151 > This issue was found during running JDG functional test suite for configuration examples provided with JDG. -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2624) JDG: Storage-only example: HotRodDecoder: NSEE: key not found: node1/clustered

by Tomas Sykora (JIRA)

Tomas Sykora created ISPN-2624: ---------------------------------- Summary: JDG: Storage-only example: HotRodDecoder: NSEE: key not found: node1/clustered Key: ISPN-2624 URL: https://issues.jboss.org/browse/ISPN-2624 Project: Infinispan Issue Type: Bug Reporter: Tomas Sykora Assignee: Mircea Markus This is issue to distinguish from https://issues.jboss.org/browse/ISPN-2550. For logs and more info see related BZ: https://bugzilla.redhat.com/show_bug.cgi?id=875151 This issue was found during running JDG functional test suite for configuration examples provided with JDG. -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2550) NoSuchElementException in Hot Rod Encoder

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2550?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-2550: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=886565 (was: https://bugzilla.redhat.com/show_bug.cgi?id=875151, https://bugzilla.redhat.com/show_bug.cgi?id=886565) > NoSuchElementException in Hot Rod Encoder > ----------------------------------------- > > Key: ISPN-2550 > URL: https://issues.jboss.org/browse/ISPN-2550 > Project: Infinispan > Issue Type: Bug > Components: Remote protocols > Affects Versions: 5.2.0.Beta4 > Reporter: Michal Linhard > Assignee: Galder Zamarreño > Priority: Blocker > Fix For: 5.2.0.Beta6 > > > Tomas noticed this a while ago in a specific functional test: > https://bugzilla.redhat.com/show_bug.cgi?id=875151 > I'm creating a more general JIRA, cause I'm having this in resilience test. > What I found by quick debug, is that here: > https://github.com/infinispan/infinispan/blob/master/server/hotrod/src/ma... > {code} > for (segmentIdx <- 0 until numSegments) { > val denormalizedSegmentHashIds = allDenormalizedHashIds(segmentIdx) > val segmentOwners = ch.locateOwnersForSegment(segmentIdx) > for (ownerIdx <- 0 until segmentOwners.length) { > val address = segmentOwners(ownerIdx % segmentOwners.size) > val serverAddress = members(address) > val hashId = denormalizedSegmentHashIds(ownerIdx) > log.tracef("Writing hash id %d for %s:%s", hashId, serverAddress.host, serverAddress.port) > writeString(serverAddress.host, buf) > writeUnsignedShort(serverAddress.port, buf) > buf.writeInt(hashId) > } > } > {code} > we're trying to obtain serverAddress for nonexistent address and NoSuchElementException is not handled properly. > It hapens after I kill a node in a resilience test and the exception appears when querying for the node in the members cache. -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2550) NoSuchElementException in Hot Rod Encoder

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2550?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-2550: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=875151, https://bugzilla.redhat.com/show_bug.cgi?id=886565 (was: https://bugzilla.redhat.com/show_bug.cgi?id=875151) > NoSuchElementException in Hot Rod Encoder > ----------------------------------------- > > Key: ISPN-2550 > URL: https://issues.jboss.org/browse/ISPN-2550 > Project: Infinispan > Issue Type: Bug > Components: Remote protocols > Affects Versions: 5.2.0.Beta4 > Reporter: Michal Linhard > Assignee: Galder Zamarreño > Priority: Blocker > Fix For: 5.2.0.Beta6 > > > Tomas noticed this a while ago in a specific functional test: > https://bugzilla.redhat.com/show_bug.cgi?id=875151 > I'm creating a more general JIRA, cause I'm having this in resilience test. > What I found by quick debug, is that here: > https://github.com/infinispan/infinispan/blob/master/server/hotrod/src/ma... > {code} > for (segmentIdx <- 0 until numSegments) { > val denormalizedSegmentHashIds = allDenormalizedHashIds(segmentIdx) > val segmentOwners = ch.locateOwnersForSegment(segmentIdx) > for (ownerIdx <- 0 until segmentOwners.length) { > val address = segmentOwners(ownerIdx % segmentOwners.size) > val serverAddress = members(address) > val hashId = denormalizedSegmentHashIds(ownerIdx) > log.tracef("Writing hash id %d for %s:%s", hashId, serverAddress.host, serverAddress.port) > writeString(serverAddress.host, buf) > writeUnsignedShort(serverAddress.port, buf) > buf.writeInt(hashId) > } > } > {code} > we're trying to obtain serverAddress for nonexistent address and NoSuchElementException is not handled properly. > It hapens after I kill a node in a resilience test and the exception appears when querying for the node in the members cache. -- 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

12 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues December 2012