July 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5620) Create PendingLockManager

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5620?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5620: ------------------------------ Status: Open (was: New) > Create PendingLockManager > ------------------------- > > Key: ISPN-5620 > URL: https://issues.jboss.org/browse/ISPN-5620 > Project: Infinispan > Issue Type: Sub-task > Components: Core > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 8.0.0.Beta2 > > > PendingLockManager will be responsible to check for older topology id transaction that may have locks acquired. Newer transactions would have to wait for them to complete before proceeding in lock acquisition. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5620) Create PendingLockManager

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-5620?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-5620: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3594 > Create PendingLockManager > ------------------------- > > Key: ISPN-5620 > URL: https://issues.jboss.org/browse/ISPN-5620 > Project: Infinispan > Issue Type: Sub-task > Components: Core > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 8.0.0.Beta2 > > > PendingLockManager will be responsible to check for older topology id transaction that may have locks acquired. Newer transactions would have to wait for them to complete before proceeding in lock acquisition. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5620) Create PendingLockManager

by Pedro Ruivo (JIRA)

Pedro Ruivo created ISPN-5620: --------------------------------- Summary: Create PendingLockManager Key: ISPN-5620 URL: https://issues.jboss.org/browse/ISPN-5620 Project: Infinispan Issue Type: Sub-task Components: Core Reporter: Pedro Ruivo Assignee: Pedro Ruivo Fix For: 8.0.0.Beta2 PendingLockManager will be responsible to check for older topology id transaction that may have locks acquired. Newer transactions would have to wait for them to complete before proceeding in lock acquisition. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5619) Implement segment listeners for distributed streams

by William Burns (JIRA)

William Burns created ISPN-5619: ----------------------------------- Summary: Implement segment listeners for distributed streams Key: ISPN-5619 URL: https://issues.jboss.org/browse/ISPN-5619 Project: Infinispan Issue Type: Enhancement Components: Core Affects Versions: 8.0.0.Beta1 Reporter: William Burns Assignee: William Burns Fix For: 8.0.0.CR1, 8.0.0.Final Distributed streams were added for ISPN-5293. However segment completion listeners are not yet added and thus EntryRetriever is still required for that case. This is to add support for listener completion so we can remove EntryRetriever references. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5619) Implement segment listeners for distributed streams

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5619?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5619: -------------------------------- Status: Open (was: New) > Implement segment listeners for distributed streams > --------------------------------------------------- > > Key: ISPN-5619 > URL: https://issues.jboss.org/browse/ISPN-5619 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 8.0.0.Beta1 > Reporter: William Burns > Assignee: William Burns > Fix For: 8.0.0.CR1, 8.0.0.Final > > > Distributed streams were added for ISPN-5293. However segment completion listeners are not yet added and thus EntryRetriever is still required for that case. This is to add support for listener completion so we can remove EntryRetriever references. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5619) Implement segment listeners for distributed streams

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5619?page=com.atlassian.jira.plugin.... ] Work on ISPN-5619 started by William Burns. ------------------------------------------- > Implement segment listeners for distributed streams > --------------------------------------------------- > > Key: ISPN-5619 > URL: https://issues.jboss.org/browse/ISPN-5619 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 8.0.0.Beta1 > Reporter: William Burns > Assignee: William Burns > Fix For: 8.0.0.CR1, 8.0.0.Final > > > Distributed streams were added for ISPN-5293. However segment completion listeners are not yet added and thus EntryRetriever is still required for that case. This is to add support for listener completion so we can remove EntryRetriever references. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5452) Query Execution using Hibernate Search slow for large volume data

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-5452?page=com.atlassian.jira.plugin.... ] Sanne Grinovero commented on ISPN-5452: --------------------------------------- I've been looking at the method invocations, and agree with you that {{HSQueryImpl.buildSearcher(}} seems to be a significant difference. But exploring further, they both invoke ultimately the method {{CRC32.updateBytes(int, byte[], int, int)}}, which is the slow point. In the Infinispan Query case this consumes 7.39%, in the RMI based example this consumes 2.02%. Your profiling results are sampling, so it's possible that one case seems higher *relatively* as it's being invoked more (looks like we agree on the conclusion so far?). But what I'm reading out of this, is not that Infinispan Query decides to not reuse the IndexReader but instead decides to reopen it, what I'm reading is that the Infinispan Query scenario is running many more queries. Could you confirm this by running a profiler section - or just logging - to count how many queries one case is doing vs how many queries the other is doing? I can't read that from sampling output, but in case I think there's a problem with your benchmark, maybe because the Infinispan Query case is faster you're getting many more queries done on it and that would explain the higher rate of index reader reopening events. > Query Execution using Hibernate Search slow for large volume data > ----------------------------------------------------------------- > > Key: ISPN-5452 > URL: https://issues.jboss.org/browse/ISPN-5452 > Project: Infinispan > Issue Type: Bug > Components: Configuration, Remote Querying > Affects Versions: 7.2.1.Final > Environment: Linux > Reporter: Prashant Thakur > Attachments: profiling_results.7z > > > While benchmarking Infinispan we found that Querying is very slow when compared with Hibernate Search in Isolation > Single node of Infinispan > Memory allocated 230GB. No GC seen throughout query operation. > Total required after full GC was 122GB. > Setup 240 million records each of avg size 330 bytes . > System has 16 cores and 40 worker threads were allocated at server side. > With Single Client thread throughput was 900 req/sec in remote and 3k per sec in embedded more same request with Hibernate Search in Isolation gives throughput of 14000 req/sec. > For 50 threads of clients the throughput was limited to 15k req/sec while hibernate search gives 80k req/sec for 10 threads. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5597) Verify if clustered Arquillian based tests are really clustered

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5597?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5597: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 8.0.0.Beta2 Resolution: Done > Verify if clustered Arquillian based tests are really clustered > --------------------------------------------------------------- > > Key: ISPN-5597 > URL: https://issues.jboss.org/browse/ISPN-5597 > Project: Infinispan > Issue Type: Task > Components: Test Suite - Query, Test Suite - Server > Reporter: Sanne Grinovero > Assignee: Martin Gencur > Priority: Critical > Fix For: 8.0.0.Beta2 > > > I just identified ARQ-1964 while debugging a clustered issue, and I think this affects the reliability of many tests in Infinispan. > The essence is that while you might think you're testing things on containers \{A,B\}, and so doing able to verify the cross-node synchronisations, you're actually always testing couples \{A,A\} or \{B,B\}. It's possible that some things actually don't work as expected even if the tests are passing. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5618) Upgrade to WildFly 9.0.0.Final

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5618?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5618: ---------------------------------- Status: Open (was: New) > Upgrade to WildFly 9.0.0.Final > ------------------------------ > > Key: ISPN-5618 > URL: https://issues.jboss.org/browse/ISPN-5618 > Project: Infinispan > Issue Type: Task > Components: Server > Affects Versions: 8.0.0.Beta1 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.0.0.Beta2, 8.0.0.Final > > > Now that WildFly 9.0.0.Final is out, we should upgrade our server to it. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5618) Upgrade to WildFly 9.0.0.Final

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5618?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5618: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3593 > Upgrade to WildFly 9.0.0.Final > ------------------------------ > > Key: ISPN-5618 > URL: https://issues.jboss.org/browse/ISPN-5618 > Project: Infinispan > Issue Type: Task > Components: Server > Affects Versions: 8.0.0.Beta1 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.0.0.Beta2, 8.0.0.Final > > > Now that WildFly 9.0.0.Final is out, we should upgrade our server to it. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2015