February 2013 - infinispan-issues

[JBoss JIRA] (ISPN-2808) Make Infinispan use its own thread pool for sending messages in order to avoid thread deadlocks

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-2808?page=com.atlassian.jira.plugin.... ] Pedro Ruivo commented on ISPN-2808: ----------------------------------- Hi Bela. Thanks for the warning =) I haven't noticed the unfinished JIRA > Make Infinispan use its own thread pool for sending messages in order to avoid thread deadlocks > ----------------------------------------------------------------------------------------------- > > Key: ISPN-2808 > URL: https://issues.jboss.org/browse/ISPN-2808 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Pedro Ruivo > Fix For: 5.3.0.Beta1, 5.3.0.Final > > > - when an OOB thread sends a sync request it blocks waiting on a sync in jgroups RequestCorrelator > - it gets released by an another OOB thread when the remote node responds > Now if all the OOB threads are blocked in sending, then there's no available OOB thread to unblock them even if responses from remote nodes have arrived - deadlock. In order to avoid this deadlock we can use a different thread pool for sending OOB messages. > For a discussion around this please refer to: http://infinispan.markmail.org/search/#query:%20list%3Aorg.jboss.lists.in... -- 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

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2866) EmbeddedCacheManager.defineConfiguration(...) should be thread safe

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2866?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-2866: ------------------------------------ Do you have a log/stack trace for the NPE you are seeing? Based on the stacktrace, I think AS7-6639 is a duplicate of ISPN-2796. However this issue looks very different, because that NPE only happens during {{getCache()}}, NOT during {{defineConfiguration()}}. > EmbeddedCacheManager.defineConfiguration(...) should be thread safe > ------------------------------------------------------------------- > > Key: ISPN-2866 > URL: https://issues.jboss.org/browse/ISPN-2866 > Project: Infinispan > Issue Type: Feature Request > Components: Configuration > Affects Versions: 5.2.1.Final > Reporter: Radoslav Husar > Assignee: Dan Berindei > Priority: Critical > Fix For: 5.2.3.Final > > > Defining configuration really should be thread safe. > In AS we will temporarily workaround per AS7-6639. > The issue was uncovered after we started seeing NPE from https://github.com/infinispan/infinispan/commit/f0beece095acb273a18bbef05... -- 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

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2808) Make Infinispan use its own thread pool for sending messages in order to avoid thread deadlocks

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/ISPN-2808?page=com.atlassian.jira.plugin.... ] Bela Ban commented on ISPN-2808: -------------------------------- Hi Pedro, saw you started working on this. Note that there is still a JGroups JIRA left [1], so the AIA might still change slightly... If it does change, it should be a small change for you though... [1] https://issues.jboss.org/browse/JGRP-1602 > Make Infinispan use its own thread pool for sending messages in order to avoid thread deadlocks > ----------------------------------------------------------------------------------------------- > > Key: ISPN-2808 > URL: https://issues.jboss.org/browse/ISPN-2808 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Pedro Ruivo > Fix For: 5.3.0.Beta1, 5.3.0.Final > > > - when an OOB thread sends a sync request it blocks waiting on a sync in jgroups RequestCorrelator > - it gets released by an another OOB thread when the remote node responds > Now if all the OOB threads are blocked in sending, then there's no available OOB thread to unblock them even if responses from remote nodes have arrived - deadlock. In order to avoid this deadlock we can use a different thread pool for sending OOB messages. > For a discussion around this please refer to: http://infinispan.markmail.org/search/#query:%20list%3Aorg.jboss.lists.in... -- 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

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2866) EmbeddedCacheManager.defineConfiguration(...) should be thread safe

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2866?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2866: -------------------------------- Assignee: Dan Berindei (was: Mircea Markus) > EmbeddedCacheManager.defineConfiguration(...) should be thread safe > ------------------------------------------------------------------- > > Key: ISPN-2866 > URL: https://issues.jboss.org/browse/ISPN-2866 > Project: Infinispan > Issue Type: Feature Request > Components: Configuration > Affects Versions: 5.2.1.Final > Reporter: Radoslav Husar > Assignee: Dan Berindei > Priority: Critical > Fix For: 5.2.3.Final > > > Defining configuration really should be thread safe. > In AS we will temporarily workaround per AS7-6639. > The issue was uncovered after we started seeing NPE from https://github.com/infinispan/infinispan/commit/f0beece095acb273a18bbef05... -- 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

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2808) Make Infinispan use its own thread pool for sending messages in order to avoid thread deadlocks

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-2808?page=com.atlassian.jira.plugin.... ] Work on ISPN-2808 started by Pedro Ruivo. > Make Infinispan use its own thread pool for sending messages in order to avoid thread deadlocks > ----------------------------------------------------------------------------------------------- > > Key: ISPN-2808 > URL: https://issues.jboss.org/browse/ISPN-2808 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Pedro Ruivo > Fix For: 5.3.0.Beta1, 5.3.0.Final > > > - when an OOB thread sends a sync request it blocks waiting on a sync in jgroups RequestCorrelator > - it gets released by an another OOB thread when the remote node responds > Now if all the OOB threads are blocked in sending, then there's no available OOB thread to unblock them even if responses from remote nodes have arrived - deadlock. In order to avoid this deadlock we can use a different thread pool for sending OOB messages. > For a discussion around this please refer to: http://infinispan.markmail.org/search/#query:%20list%3Aorg.jboss.lists.in... -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2856) Implement support for JSR-107 CacheEntryExpiredListener

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2856?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-2856: ----------------------------------- Status: Pull Request Sent (was: Reopened) Git Pull Request: https://github.com/infinispan/infinispan/pull/1686 > Implement support for JSR-107 CacheEntryExpiredListener > ------------------------------------------------------- > > Key: ISPN-2856 > URL: https://issues.jboss.org/browse/ISPN-2856 > Project: Infinispan > Issue Type: Sub-task > Components: Listeners > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 5.3.0.Alpha1 > > > Not covered by TCK in version 0.6. -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2639) Write an adaptor for the JSR 107 API

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2639?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-2639: ---------------------------------------- Pull request sent, TCK currently at: {code}Tests run: 286, Failures: 0, Errors: 0, Skipped: 0{code} > Write an adaptor for the JSR 107 API > ------------------------------------ > > Key: ISPN-2639 > URL: https://issues.jboss.org/browse/ISPN-2639 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Galder Zamarreño > Fix For: 5.3.0.Final > > > This should be a new Infinispan maven module, implement the API and pass the TCK suite as defined here: https://github.com/jsr107 -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2766) Improve and adapt notification model to fit JSR107 notification model

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2766?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-2766: ----------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/1686 > Improve and adapt notification model to fit JSR107 notification model > --------------------------------------------------------------------- > > Key: ISPN-2766 > URL: https://issues.jboss.org/browse/ISPN-2766 > Project: Infinispan > Issue Type: Sub-task > Components: Listeners > Affects Versions: 5.2.0.CR3 > Reporter: Vladimir Blagojevic > Assignee: Galder Zamarreño > Fix For: 5.3.0.Alpha1 > > > Out current notification (listener) model does not fit JSR 107 notification model and thus needs a slight adaptation in order to implement JSR 107. > More specifically the problem is with JSR107 CacheEntryCreatedListener and CacheEntryExpiredListener. > The first one is not easy to implement because we need both key/value pair for jsr listener and our CacheEntryCreatedEvent does not provide value. > The second is related to CacheEntryExpired event. True, spec is not rigorous that such an event has to be fired immediately after an entry has expired but eventually (which might be on access). However, we do not have such an event at all as of now. > -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2639) Write an adaptor for the JSR 107 API

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2639?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-2639: ----------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/1686 > Write an adaptor for the JSR 107 API > ------------------------------------ > > Key: ISPN-2639 > URL: https://issues.jboss.org/browse/ISPN-2639 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Galder Zamarreño > Fix For: 5.3.0.Final > > > This should be a new Infinispan maven module, implement the API and pass the TCK suite as defined here: https://github.com/jsr107 -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2767) Retrofit storeAsBinary to allow implementation of JSR107 store by value

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2767?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-2767: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/1686 > Retrofit storeAsBinary to allow implementation of JSR107 store by value > ------------------------------------------------------------------------ > > Key: ISPN-2767 > URL: https://issues.jboss.org/browse/ISPN-2767 > Project: Infinispan > Issue Type: Sub-task > Components: Core API, Marshalling > Affects Versions: 5.2.0.CR3 > Reporter: Vladimir Blagojevic > Assignee: Galder Zamarreño > Fix For: 5.3.0.Alpha1 > > > storeAsBinary in Infinispan was designed with the following purposes in mind, in order of importance: > 1) Performance. Prevent serialising/deserializing an entry multiple times (e.g., to write through to disk, to replicate over the network, concurrent threads needing to read the object representation). > 2) Classloader isolation (as Galder mentioned). This became a secondary purpose of this feature (originally observed as a side-effect). Enhanced by allowing storeKeyAsBinary and storeValueAsBinary options for more fine-grained control of this behaviour. > Now lets consider what JSR 107 needs. Similarly named, the feature in JSR 107 serves a completely different purpose, and this is referential integrity. Think database-style isolation (repeatable read, etc) where concurrent threads holding object references to the same value, and mutating the same value, are not visible until a commit. > I originally thought that Infinispan's storeAsBinary can be used for this, but apparently not without some additional changes/tweaks. Maybe we need: > 1) A new config option for this behaviour. <storeAsBinary defensive="true" /> ? > 2) If enabled, maybe use a subclass of MarshalledValue (DefensiveMarshalledValue?) that *always* stores a byte[] and never caches the object representation? -- 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

11 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 February 2013