August 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-1239) Graceful shutdown should be supported

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-1239?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-1239: ----------------------------------------------- Paul Ferraro <paul.ferraro(a)redhat.com> made a comment on [bug 919399|https://bugzilla.redhat.com/show_bug.cgi?id=919399] Does not appear to be an issue anymore. > Graceful shutdown should be supported > ------------------------------------- > > Key: ISPN-1239 > URL: https://issues.jboss.org/browse/ISPN-1239 > Project: Infinispan > Issue Type: Feature Request > Components: Distributed Cache > Affects Versions: 5.0.0.FINAL > Reporter: Manik Surtani > Assignee: Dan Berindei > Priority: Critical > Labels: clean_shutdown, rehashing > > Currently, killing any node will result in a rehash. A mechanism for clean shutdown should also be supported, so that a rehash is *not* triggered. Useful when the entire cluster is being intentionally brought down. > Need to think about how we do this; perhaps a LEAVE message that will prevent nodes triggering a rehash when a subsequent view change is detected. This could be done programmatically via a {{clean}} parameter to {{stop()}}, but we should explore alternatives here. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2989) View rollback never unlocks stateTransferLock

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2989?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2989: ----------------------------------------------- Paul Ferraro <paul.ferraro(a)redhat.com> changed the Status of [bug 947614|https://bugzilla.redhat.com/show_bug.cgi?id=947614] from NEW to CLOSED > View rollback never unlocks stateTransferLock > --------------------------------------------- > > Key: ISPN-2989 > URL: https://issues.jboss.org/browse/ISPN-2989 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.1.7.Final > Reporter: Dennis Reed > Assignee: Dan Berindei > > When a new cache view prepare fails and is rolled back (for example due to a TimeoutException), the state transfer lock is never released, causing all future operations to fail with a StateTransferInProgressException timeout. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2898) Web Cache fails to start when multiple apps are trying to create it

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2898?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2898: ----------------------------------------------- Paul Ferraro <paul.ferraro(a)redhat.com> made a comment on [bug 918791|https://bugzilla.redhat.com/show_bug.cgi?id=918791] We can backport the GlobalComponentRegistryService from upstream master. This should alleviate the problem significantly. > Web Cache fails to start when multiple apps are trying to create it > ------------------------------------------------------------------- > > Key: ISPN-2898 > URL: https://issues.jboss.org/browse/ISPN-2898 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.1.7.Final > Reporter: Shay Matasaro > Assignee: Dan Berindei > Fix For: 6.0.0.Final > > > When multiple apps are trying to create/connect to the web cache , the fist one get a lock on the cache manager, and prevents the others from starting it in a timely manner -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3452) Hot Rod client socket leak

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3452?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3452: ----------------------------------------------- Michal Linhard <mlinhard(a)redhat.com> made a comment on [bug 1002653|https://bugzilla.redhat.com/show_bug.cgi?id=1002653] problem in current Infinispan master i.e. affects JDG.6.2.0.DR3 https://issues.jboss.org/browse/ISPN-3452 > Hot Rod client socket leak > -------------------------- > > Key: ISPN-3452 > URL: https://issues.jboss.org/browse/ISPN-3452 > Project: Infinispan > Issue Type: Bug > Components: Remote protocols > Affects Versions: 5.3.0.Final, 6.0.0.Alpha3 > Reporter: Michal Linhard > Assignee: Galder Zamarreño > Priority: Critical > > TransportObjectFactory.validateObject swallows TransportException and doesn't properly close socket connected with the TcpTransport object. > This way an open socket is leaked each time it's created by connection pool Evictor thread -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3452) Hot Rod client socket leak

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3452?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-3452: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1002653 > Hot Rod client socket leak > -------------------------- > > Key: ISPN-3452 > URL: https://issues.jboss.org/browse/ISPN-3452 > Project: Infinispan > Issue Type: Bug > Components: Remote protocols > Affects Versions: 5.3.0.Final, 6.0.0.Alpha3 > Reporter: Michal Linhard > Assignee: Galder Zamarreño > Priority: Critical > > TransportObjectFactory.validateObject swallows TransportException and doesn't properly close socket connected with the TcpTransport object. > This way an open socket is leaked each time it's created by connection pool Evictor thread -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2989) View rollback never unlocks stateTransferLock

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2989?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2989: ----------------------------------------------- Paul Ferraro <paul.ferraro(a)redhat.com> made a comment on [bug 947614|https://bugzilla.redhat.com/show_bug.cgi?id=947614] Per #c1 > View rollback never unlocks stateTransferLock > --------------------------------------------- > > Key: ISPN-2989 > URL: https://issues.jboss.org/browse/ISPN-2989 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.1.7.Final > Reporter: Dennis Reed > Assignee: Dan Berindei > > When a new cache view prepare fails and is rolled back (for example due to a TimeoutException), the state transfer lock is never released, causing all future operations to fail with a StateTransferInProgressException timeout. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3442) Query API DSL returns bad result on calling negated between() with includeUpper/Lower(false)

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3442?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-3442: -------------------------------- Status: Resolved (was: Pull Request Sent) Assignee: Jiří Holuša (was: Sanne Grinovero) Resolution: Done Integrated in master. Thanks! > Query API DSL returns bad result on calling negated between() with includeUpper/Lower(false) > -------------------------------------------------------------------------------------------- > > Key: ISPN-3442 > URL: https://issues.jboss.org/browse/ISPN-3442 > Project: Infinispan > Issue Type: Bug > Components: Querying > Reporter: Jiří Holuša > Assignee: Jiří Holuša > > Assuming existing of three users with IDs 1,2 and 3. > Then this code's result is incorrect. > {code:border=solid} > Query q = queryFactory.from(User.class) > .not().having("id").between(1, 2).includeLower(false) > .toBuilder().build(); > {code} > It returns no user whereas it should return two users with IDs 1 and 3. I debugged the org.infinispan.query.dsl.impl.JPAQueryGeneratorVisitor and found the problem in visit(BetweenOperator operator). > The code correctly changes the </<= and >/>= operators if between operator is negated, but forgets to change "AND" to "OR". > Thus the generated string query ends up like "id <= 1 AND id > 2" which is of course always empty result. > The pull request contains fix to this bug and also extended tests for Query API DSL to increase code coverage. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3442) Query API DSL returns bad result on calling negated between() with includeUpper/Lower(false)

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3442?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-3442: -------------------------------- Fix Version/s: 6.0.0.Beta1 Affects Version/s: 6.0.0.Alpha2 > Query API DSL returns bad result on calling negated between() with includeUpper/Lower(false) > -------------------------------------------------------------------------------------------- > > Key: ISPN-3442 > URL: https://issues.jboss.org/browse/ISPN-3442 > Project: Infinispan > Issue Type: Bug > Components: Querying > Affects Versions: 6.0.0.Alpha2 > Reporter: Jiří Holuša > Assignee: Jiří Holuša > Fix For: 6.0.0.Beta1 > > > Assuming existing of three users with IDs 1,2 and 3. > Then this code's result is incorrect. > {code:border=solid} > Query q = queryFactory.from(User.class) > .not().having("id").between(1, 2).includeLower(false) > .toBuilder().build(); > {code} > It returns no user whereas it should return two users with IDs 1 and 3. I debugged the org.infinispan.query.dsl.impl.JPAQueryGeneratorVisitor and found the problem in visit(BetweenOperator operator). > The code correctly changes the </<= and >/>= operators if between operator is negated, but forgets to change "AND" to "OR". > Thus the generated string query ends up like "id <= 1 AND id > 2" which is of course always empty result. > The pull request contains fix to this bug and also extended tests for Query API DSL to increase code coverage. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1965) Some entries not available during view change

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1965?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-1965: ------------------------------------- [~mgencur] There are two types of view changes: nodes leaving/joing a partition, and the cluster splitting in two (or more) sub-partitions (split-brains). NBST only works in the scope of the former. > Some entries not available during view change > --------------------------------------------- > > Key: ISPN-1965 > URL: https://issues.jboss.org/browse/ISPN-1965 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.1.3.FINAL > Reporter: Michal Linhard > Assignee: Dan Berindei > > In the 4 node, dist mode, num-owners=2, elasticity test > http://www.qa.jboss.com/~mlinhard/hyperion/run44-elas-dist/ > there is a cca 90 sec period of time where clients get null responses to GET > requests on entries that should exist in the cache. > first occurence: > hyperion1139.log 05:31:01,202 286.409 > last occurence: > hyperion1135.log 05:32:45,441 390.648 > total occurence count: (in all 19 driver nodes) > 152241 > (this doesn't mean it happens for 152K keys, because each key is retried after > erroneous attempt) > data doesn't seem to be lost, because these errors cease after a while and > number of entries returns back to normal (see cache_entries.csv) > this happens approximately in the period between node0001 is killed and cluster > {node0002 - node0004} is formed (and shortly after). -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3194) Create diagnostics dumping tool

by Manik Surtani (JIRA)

[ https://issues.jboss.org/browse/ISPN-3194?page=com.atlassian.jira.plugin.... ] Manik Surtani commented on ISPN-3194: ------------------------------------- [~NadirX] - there is a bit here ( https://access.redhat.com/site/solutions/221103 ) about JDR but it doesn't really tell you what is being captured from the runtime. It seems to be more of a tool to zip up configs and logs. Do you have any more info on JDR? > Create diagnostics dumping tool > ------------------------------- > > Key: ISPN-3194 > URL: https://issues.jboss.org/browse/ISPN-3194 > Project: Infinispan > Issue Type: Feature Request > Components: Core API > Affects Versions: 5.3.0.Final > Reporter: Manik Surtani > Assignee: Mircea Markus > Labels: diagnostics > > A simple script that an end-user can run on an existing cluster, that will: > 1. Connect to a given node via JMX > 2. Get a list of all caches on all nodes > 3. Run JMX calls on each cache on each node to capture diagnostic data > 4. Serialise this data (maybe JSON?), zip it up. > This will allow end-users to share such stats for debugging and perf tuning. > Diagnostic data to be captured would include all JMX info on hit/miss ratio, RPC performance, transaction commit/rollback rates, config details, time budgeting info, etc. > This tool would require that JMX statistics are enabled and running for a while before the snapshot is captured. -- 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, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues August 2013