October 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3183) HotRod RollUps from 5.2 to 5.3 -- target can't obtain formerly stored data from RCS

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3183?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3183: ----------------------------------------------- Martin Gencur <mgencur(a)redhat.com> made a comment on [bug 986307|https://bugzilla.redhat.com/show_bug.cgi?id=986307] Shouldn't this be ON_QA? > HotRod RollUps from 5.2 to 5.3 -- target can't obtain formerly stored data from RCS > ----------------------------------------------------------------------------------- > > Key: ISPN-3183 > URL: https://issues.jboss.org/browse/ISPN-3183 > Project: Infinispan > Issue Type: Bug > Reporter: Tomas Sykora > Assignee: Tristan Tarrant > Priority: Critical > Labels: jdg62blocker > Fix For: 6.0.0.Beta2 > > Attachments: 52to52sourceTrace, 52to52targetTrace, 52to53sourceTrace, 52to53targetTrace > > > Scenario (typical for rollups): > Start source node, put entries. > Start target node which is pointing to source (source is his RemoteCacheStore now) and try to get entries. > For 5.2 to 5.2 working perfectly. > For 5.2 source and 5.3 target -- we have problems here. > Sorry that I can't provide any valuable info beside TRACEs. > 4 TRACE logs -- rollups from 5.2 to 5.2 source log and target log + rollups from 5.2 to 5.3 source log and target log. > Very quick summary: > 5.2 to 5.2 on target: Entry exists in loader? true > 5.2 to 5.3 on targer: > 16:21:41,508 TRACE [org.infinispan.container.EntryFactoryImpl] (HotRodServerWorker-2) Exists in context? null > 16:21:41,508 TRACE [org.infinispan.container.EntryFactoryImpl] (HotRodServerWorker-2) Retrieved from container null > What changed in RemoteCacheStore. What changed in HotRod? Any idea? Let me know, thank you! > -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3507) EntrySet operation in cache with LevelDB store ignores expiration

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3507?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3507: ----------------------------------------------- Michal Linhard <mlinhard(a)redhat.com> made a comment on [bug 1007947|https://bugzilla.redhat.com/show_bug.cgi?id=1007947] Verified for 6.2.0.ER2 > EntrySet operation in cache with LevelDB store ignores expiration > ----------------------------------------------------------------- > > Key: ISPN-3507 > URL: https://issues.jboss.org/browse/ISPN-3507 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 6.0.0.Alpha4 > Reporter: Michal Linhard > Assignee: Mircea Markus > Priority: Critical > Labels: jdg62blocker > Fix For: 6.0.0.Beta2 > > > In cache with leveldb cache store, expired entry still appears in collection returned by entrySet operation. > test: > https://github.com/mlinhard/infinispan-cachestore-leveldb/commit/71b62c19... -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3588) CacheManager.startCaches ignores exceptions if cache fails to start

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3588?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3588: ------------------------------ Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2147 > CacheManager.startCaches ignores exceptions if cache fails to start > ------------------------------------------------------------------- > > Key: ISPN-3588 > URL: https://issues.jboss.org/browse/ISPN-3588 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.CR1 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 6.0.0.Final, 6.1.0.Final > > > {code}startCaches(){code} creates a thread for each cache name and if a cache fails to start, the invoker is never notified and the start count down latch is released. > the result is the application using the cache without be aware of the fail. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3600) ignorePreviousValue should not be set on non-origin nodes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3600?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-3600: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1016104 > ignorePreviousValue should not be set on non-origin nodes > --------------------------------------------------------- > > Key: ISPN-3600 > URL: https://issues.jboss.org/browse/ISPN-3600 > Project: Infinispan > Issue Type: Bug > Components: State transfer, Transactions > Affects Versions: 6.0.0.CR1 > Reporter: Radim Vansa > Assignee: Mircea Markus > Priority: Critical > > In {{TxDistributionInterceptor.visit(Replace|Remove)Command}} the ignorePreviousValue flag is set to false on nodes which are not executing the transaction. Usually this does not matter, but when some other node requests transactions from this node (during ST), the Remove and Replace commands are sent with this flag set to false, which results in skipping their execution. > Note: the overall behaviour with ignoring the command when this flag is false and origin is not local seems to me as abusing it - the semantics of the command is far from obvious. When the non-origin node receives the exact command that is executed on the original node (without ignorePreviousValue set to true), it simply ignores it. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3600) ignorePreviousValue should not be set on non-origin nodes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3600?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3600: ----------------------------------------------- Radim Vansa <rvansa(a)redhat.com> made a comment on [bug 1016104|https://bugzilla.redhat.com/show_bug.cgi?id=1016104] In TxDistributionInterceptor.visit(Replace|Remove)Command the ignorePreviousValue flag is set to false on nodes which are not executing the transaction. Usually this does not matter, but when some other node requests transactions from this node (during ST), the Remove and Replace commands are sent with this flag set to false, which results in skipping their execution. > ignorePreviousValue should not be set on non-origin nodes > --------------------------------------------------------- > > Key: ISPN-3600 > URL: https://issues.jboss.org/browse/ISPN-3600 > Project: Infinispan > Issue Type: Bug > Components: State transfer, Transactions > Affects Versions: 6.0.0.CR1 > Reporter: Radim Vansa > Assignee: Mircea Markus > Priority: Critical > > In {{TxDistributionInterceptor.visit(Replace|Remove)Command}} the ignorePreviousValue flag is set to false on nodes which are not executing the transaction. Usually this does not matter, but when some other node requests transactions from this node (during ST), the Remove and Replace commands are sent with this flag set to false, which results in skipping their execution. > Note: the overall behaviour with ignoring the command when this flag is false and origin is not local seems to me as abusing it - the semantics of the command is far from obvious. When the non-origin node receives the exact command that is executed on the original node (without ignorePreviousValue set to true), it simply ignores it. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3600) ignorePreviousValue should not be set on non-origin nodes

by Radim Vansa (JIRA)

Radim Vansa created ISPN-3600: --------------------------------- Summary: ignorePreviousValue should not be set on non-origin nodes Key: ISPN-3600 URL: https://issues.jboss.org/browse/ISPN-3600 Project: Infinispan Issue Type: Bug Components: State transfer, Transactions Affects Versions: 6.0.0.CR1 Reporter: Radim Vansa Assignee: Mircea Markus Priority: Critical In {{TxDistributionInterceptor.visit(Replace|Remove)Command}} the ignorePreviousValue flag is set to false on nodes which are not executing the transaction. Usually this does not matter, but when some other node requests transactions from this node (during ST), the Remove and Replace commands are sent with this flag set to false, which results in skipping their execution. Note: the overall behaviour with ignoring the command when this flag is false and origin is not local seems to me as abusing it - the semantics of the command is far from obvious. When the non-origin node receives the exact command that is executed on the original node (without ignorePreviousValue set to true), it simply ignores it. -- 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, 6 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> changed the Status of [bug 1002653|https://bugzilla.redhat.com/show_bug.cgi?id=1002653] from ON_QA to VERIFIED > 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: Mircea Markus > Priority: Critical > Labels: jdg62blocker > Fix For: 6.0.0.Beta2 > > > 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

12 years, 6 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] Verified for 6.2.0.ER2 test: https://github.com/mlinhard/samples/tree/master/test-hotrod-socket-leak > 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: Mircea Markus > Priority: Critical > Labels: jdg62blocker > Fix For: 6.0.0.Beta2 > > > 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3598) ISPN testsuite fails for RHEL 5, 6 && IBM JDK6

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3598?page=com.atlassian.jira.plugin.... ] Tristan Tarrant commented on ISPN-3598: --------------------------------------- This looks like the *component-metadata.dat files were not regenerated and old ones used. I would check the build to verify that you are cleaning the old files. > ISPN testsuite fails for RHEL 5,6 && IBM JDK6 > --------------------------------------------- > > Key: ISPN-3598 > URL: https://issues.jboss.org/browse/ISPN-3598 > Project: Infinispan > Issue Type: Bug > Components: Core API > Affects Versions: 6.0.0.Beta1 > Environment: RHEL{5, 6} && IBM JDK6 > Reporter: Anna Manukyan > Assignee: Mircea Markus > Labels: testsuite_stability > Attachments: ibm6_infinispan_failure_rhel5_x32.log, ibm6_infinispan_failure_rhel5_x64.log, ibm6_infinispan_failure_rhel6_x32.log, ibm6_infinispan_failure_rhel6_x64.log > > > The ISPN testsuite fails for the environment specified in the description. > You can find the core module's tracelog for all configurations attached. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3599) CommitCommand with replayed PrepareCommand executes rollback and then commit

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3599?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-3599: ------------------------------------ [~rvansa], does this cause any inconsistencies? > CommitCommand with replayed PrepareCommand executes rollback and then commit > ---------------------------------------------------------------------------- > > Key: ISPN-3599 > URL: https://issues.jboss.org/browse/ISPN-3599 > Project: Infinispan > Issue Type: Bug > Components: State transfer, Transactions > Affects Versions: 6.0.0.CR1 > Reporter: Radim Vansa > Assignee: Mircea Markus > Priority: Critical > > During state-transfer in tx cache, the node can receive {{CommitCommand}} from other node. After the node gets transaction data for affected segments, it creates the transaction with {{missingLookedUpEntries=true}} and the {{CommitCommand}} can be executed. > In this command's {{perform(...)}} the transaction is *first* marked as completed, then it enters the interceptor chain. There, the {{PrepareCommand}} is created in {{StateTransferInterceptor.visitCommitCommand}} but after this is processed the {{TxInterceptor}} finds out that the transaction is already completed and executes {{RollbackCommand}}, clearing locks etc. > Nevertheless, {{StateTransferInterceptor}} executes the initial {{CommitCommand}} afterwards. I suspect that this may be executed without the locks held. > Anyway, it is not correct to execute both commit and rollback on the same transaction. -- 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, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2013