March 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-7580) Use of marsheller is not consistent in all places

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/ISPN-7580?page=com.atlassian.jira.plugin.... ] Ramesh Reddy commented on ISPN-7580: ------------------------------------ [~anistor] to be honest there isn't much magic in my code, I just extended the serialization context then injected the a marshaller in place. I would liked if all the logic would have just depend on Marshallar interface based on the "descriptor name" not class name, and {{BaseMarshaller}} interface contain the marshall/unmarshall methods rather than delegating to the {{MarshallDelegate}} interface. For me to do that, means lot more changes in your code, thus I resisted. Anyway my git repo is at [1], note this is work very much in progress. The extended marshaller and serialization context seen here [2], the most important to you may be seen in my test case here [3] which shows few scenarios, marshalling simple and complex objects how interchangeably used the stock marshellers or my custom marshaller to test the validity. Thanks for taking a look, let me know of any suggestions. [1] https://github.com/rareddy/infinispan [2] https://github.com/rareddy/infinispan/tree/master/infinispan-api/src/main... [3] https://github.com/rareddy/infinispan/blob/master/translator-infinispan-h... > Use of marsheller is not consistent in all places > ------------------------------------------------- > > Key: ISPN-7580 > URL: https://issues.jboss.org/browse/ISPN-7580 > Project: Infinispan > Issue Type: Bug > Components: Marshalling, Remote Querying > Reporter: Ramesh Reddy > Assignee: Adrian Nistor > > Usage of extended ProtoStreamMarshaller is not consistent across all the code paths. For the purposes of Teiid translator, I have extended ProtoStreamMarshaller which knows to read/write byte streams in portable fashion for given message type, which are representions of a relational table in Teiid. This works fine, if I just use cache's get/put calls. > However, the same fails when used with RemoteQuery or Continuous query. The reason is, these classes circumvent extended Marsheller and go directly to serialization context registered to do the wrapping/unwrapping. Not only that there are few places code will type cast the SerializationContext to SerializationContextImpl object. Thus I can not even provide my own Serializer nor I can extend this as SerializationContextImpl is declared as final. These need to be corrected such that extended marsheller is used rather than hard coding them. > I am guessing this is first time anyone has even done this without using dedicated java classes as marshellers. > This is extremely critical for me to be fixed to move forward, I can provide the pull request for it? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7649) Administration console - transaction tab allows to set invalid options

by Roman Macor (JIRA)

Roman Macor created ISPN-7649: --------------------------------- Summary: Administration console - transaction tab allows to set invalid options Key: ISPN-7649 URL: https://issues.jboss.org/browse/ISPN-7649 Project: Infinispan Issue Type: Bug Components: JMX, reporting and management Affects Versions: 9.0.0.CR3 Reporter: Roman Macor If a cache is set to distributed async mode, setting transactions to FULL_XA mode results in error after the cluster restart. The console shouldn't allow this combination. Suggested solution - dropdown should display only valid options for transaction mode for the given cache. (I'm not sure if this is the only invalid combination) Server error: ... org.infinispan.commons.CacheConfigurationException: ISPN000441: Unsupported async cache mode 'DIST_ASYNC' for transactional caches ... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7648) Implement @Analyzer and @Field.analyzer for protobuf

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-7648?page=com.atlassian.jira.plugin.... ] Work on ISPN-7648 started by Adrian Nistor. ------------------------------------------- > Implement @Analyzer and @Field.analyzer for protobuf > ---------------------------------------------------- > > Key: ISPN-7648 > URL: https://issues.jboss.org/browse/ISPN-7648 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.0.0.CR4, 9.0.0.Final > > > These annotations are already recognized but are not yet honoured. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7648) Implement @Analyzer and @Field.analyzer for protobuf

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-7648: ----------------------------------- Summary: Implement @Analyzer and @Field.analyzer for protobuf Key: ISPN-7648 URL: https://issues.jboss.org/browse/ISPN-7648 Project: Infinispan Issue Type: Feature Request Components: Remote Querying Reporter: Adrian Nistor Assignee: Adrian Nistor Fix For: 9.0.0.CR4 These annotations are already recognized but are not yet honoured. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7648) Implement @Analyzer and @Field.analyzer for protobuf

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-7648?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-7648: -------------------------------- Status: Open (was: New) > Implement @Analyzer and @Field.analyzer for protobuf > ---------------------------------------------------- > > Key: ISPN-7648 > URL: https://issues.jboss.org/browse/ISPN-7648 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.0.0.CR4, 9.0.0.Final > > > These annotations are already recognized but are not yet honoured. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7648) Implement @Analyzer and @Field.analyzer for protobuf

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-7648?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-7648: -------------------------------- Fix Version/s: 9.0.0.Final > Implement @Analyzer and @Field.analyzer for protobuf > ---------------------------------------------------- > > Key: ISPN-7648 > URL: https://issues.jboss.org/browse/ISPN-7648 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.0.0.CR4, 9.0.0.Final > > > These annotations are already recognized but are not yet honoured. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7642) Administration console - remote sites are not displayed correctly on cache container page

by Roman Macor (JIRA)

[ https://issues.jboss.org/browse/ISPN-7642?page=com.atlassian.jira.plugin.... ] Roman Macor commented on ISPN-7642: ----------------------------------- [^clustered.xml] [~vblagojevic] here's the configuration for standalone (it doesn't configure full remote sites with relay protocol and channels, but it sufficient to reproduce the issue). > Administration console - remote sites are not displayed correctly on cache container page > ----------------------------------------------------------------------------------------- > > Key: ISPN-7642 > URL: https://issues.jboss.org/browse/ISPN-7642 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 9.0.0.CR2 > Reporter: Roman Macor > Assignee: Vladimir Blagojevic > Attachments: Screenshot-cacheContainer.png, Screenshot-detail-cache.png, clustered.xml > > > Have 2 caches each configured with a different remote site. > When you click on cache container, both remote sites are displayed on both cache cards. Clicking on a cache to see cache detail page shows correct remote site. Please see the attached screenshots. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7642) Administration console - remote sites are not displayed correctly on cache container page

by Roman Macor (JIRA)

[ https://issues.jboss.org/browse/ISPN-7642?page=com.atlassian.jira.plugin.... ] Roman Macor updated ISPN-7642: ------------------------------ Attachment: clustered.xml > Administration console - remote sites are not displayed correctly on cache container page > ----------------------------------------------------------------------------------------- > > Key: ISPN-7642 > URL: https://issues.jboss.org/browse/ISPN-7642 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 9.0.0.CR2 > Reporter: Roman Macor > Assignee: Vladimir Blagojevic > Attachments: Screenshot-cacheContainer.png, Screenshot-detail-cache.png, clustered.xml > > > Have 2 caches each configured with a different remote site. > When you click on cache container, both remote sites are displayed on both cache cards. Clicking on a cache to see cache detail page shows correct remote site. Please see the attached screenshots. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7629) Administration console - fatal events have no icon in the right column latest events section

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-7629?page=com.atlassian.jira.plugin.... ] Ryan Emerson resolved ISPN-7629. -------------------------------- Fix Version/s: 9.0.0.CR4 Resolution: Done > Administration console - fatal events have no icon in the right column latest events section > -------------------------------------------------------------------------------------------- > > Key: ISPN-7629 > URL: https://issues.jboss.org/browse/ISPN-7629 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 9.0.0.CR2 > Reporter: Roman Macor > Assignee: Ryan Emerson > Priority: Minor > Fix For: 9.0.0.CR4 > > > Fatal events such as "Lost data" event have no icon displayed in "Latest Grid Events" column on the right. > Note: > Status Events tab displays them correctly. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-3927) rethinking ISPN transactions

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3927?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3927: ------------------------------ Description: Umbrella JIRA for several transaction related improvements: -1. Async options for commit/rollback- (DONE) - they don't really make sense as a user you don't get any guarantee on the status of the transaction - they complicate the code significantly - I think they should be removed 2. READ_COMMITTED - it has the same performance as REPEATABLE_READ, but offers less guarantees. - unlike REPEATABLE_READ, it also behaves inconsistently when the data is owned by transaction originator - I think it should be removed 3. Optimistic tx without Write Skew Check (WSC) - well, without WSC the transactions are not optimistic by definition - they are something else: an batch update of multiple key/values. If the batch is successful you know the update was atomic. If it failed you don't get any guarantee - suggestion: optimistic tx should *always* have WSC enabled (no option to configure it) - build our batching functionality on top of what currently is optimistic tx without WSC and document it as such 4. Remove 1PC option - I'm not totally sure about it, but does it really make sense to have 1PC as an option? they don't offer any consistency guarantees so async API + non tx do about the same thing 5. Configuration changes - remove (deprecate first) {{write-skew}} attribute. it will be enabled automatically when needed to keep the data consistent - -remove {{eager-locking-single-node}}. deprecated since 5.1- (DONE) - remove {{transaction-protocol}} and add {{TOTAL_ORDER}} to {{locking-mode}}. Since total order is an alternative, it makes more sense to be in the locking mode than in the separate attributed. - -remove {{eager-locking}}. deprecated since 5.1- (DONE) - move {{isolation-level}} to {{<transaction>}}. it only makes sense for transactional caches. - remove {{single-phase-auto-commit}} ?? it is 1PC for auto-commit transactions. does it make sense to have it? it doesn't provide any guarantees. 6. Internal changes - remove list of {{WriteCommand}} and keep a map between {{key}} and {{new-value, new-metadata and version-read}}. A {{null}} value means a remove operation. 7. Create a single {{XaResource}}/{{Synchronization}} per cache-manager instead of per cache. 8. For implicit transaction and {{auto-commit=true}}, if the transaction fails to commit, it can be retried until succeed. This will make the conditional operation to return a valid return value. Possible problem with retry is when a partition happens and it may fail the transaction forever. - note: conditional operations that return {{true}} or {{false}} doesn't need to retry the transaction. They can return {{false}} when the transaction fails. [1] http://markmail.org/thread/a7fjko4dyejxqgdy [2] https://github.com/infinispan/infinispan/pull/2177 [3] http://infinispan.markmail.org/thread/nl2bs7rjvayjcybv [4] http://infinispan.markmail.org/thread/vbg6g4otu7djazbc was: Umbrella JIRA for several transaction related improvements: -1. Async options for commit/rollback- (DONE) - they don't really make sense as a user you don't get any guarantee on the status of the transaction - they complicate the code significantly - I think they should be removed 2. READ_COMMITTED - it has the same performance as REPEATABLE_READ, but offers less guarantees. - unlike REPEATABLE_READ, it also behaves inconsistently when the data is owned by transaction originator - I think it should be removed 3. Optimistic tx without Write Skew Check (WSC) - well, without WSC the transactions are not optimistic by definition - they are something else: an batch update of multiple key/values. If the batch is successful you know the update was atomic. If it failed you don't get any guarantee - suggestion: optimistic tx should *always* have WSC enabled (no option to configure it) - build our batching functionality on top of what currently is optimistic tx without WSC and document it as such 4. Remove 1PC option - I'm not totally sure about it, but does it really make sense to have 1PC as an option? they don't offer any consistency guarantees so async API + non tx do about the same thing 5. Configuration changes - remove (deprecate first) {{write-skew}} attribute. it will be enabled automatically when needed to keep the data consistent - remove {{eager-locking-single-node}}. deprecated since 5.1 - remove {{transaction-protocol}} and add {{TOTAL_ORDER}} to {{locking-mode}}. Since total order is an alternative, it makes more sense to be in the locking mode than in the separate attributed. - remove {{eager-locking}}. deprecated since 5.1 - move {{isolation-level}} to {{<transaction>}}. it only makes sense for transactional caches. - remove {{single-phase-auto-commit}} ?? it is 1PC for auto-commit transactions. does it make sense to have it? it doesn't provide any guarantees. 6. Internal changes - remove list of {{WriteCommand}} and keep a map between {{key}} and {{new-value, new-metadata and version-read}}. A {{null}} value means a remove operation. 7. Create a single {{XaResource}}/{{Synchronization}} per cache-manager instead of per cache. 8. For implicit transaction and {{auto-commit=true}}, if the transaction fails to commit, it can be retried until succeed. This will make the conditional operation to return a valid return value. Possible problem with retry is when a partition happens and it may fail the transaction forever. - note: conditional operations that return {{true}} or {{false}} doesn't need to retry the transaction. They can return {{false}} when the transaction fails. [1] http://markmail.org/thread/a7fjko4dyejxqgdy [2] https://github.com/infinispan/infinispan/pull/2177 [3] http://infinispan.markmail.org/thread/nl2bs7rjvayjcybv [4] http://infinispan.markmail.org/thread/vbg6g4otu7djazbc > rethinking ISPN transactions > ---------------------------- > > Key: ISPN-3927 > URL: https://issues.jboss.org/browse/ISPN-3927 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: Mircea Markus > Assignee: Pedro Ruivo > Labels: roadmap > > Umbrella JIRA for several transaction related improvements: > -1. Async options for commit/rollback- (DONE) > - they don't really make sense as a user you don't get any guarantee on the status of the transaction > - they complicate the code significantly > - I think they should be removed > 2. READ_COMMITTED > - it has the same performance as REPEATABLE_READ, but offers less guarantees. > - unlike REPEATABLE_READ, it also behaves inconsistently when the data is owned by transaction originator > - I think it should be removed > 3. Optimistic tx without Write Skew Check (WSC) > - well, without WSC the transactions are not optimistic by definition > - they are something else: an batch update of multiple key/values. If the batch is successful you know the update was atomic. If it failed you don't get any guarantee > - suggestion: optimistic tx should *always* have WSC enabled (no option to configure it) > - build our batching functionality on top of what currently is optimistic tx without WSC and document it as such > 4. Remove 1PC option > - I'm not totally sure about it, but does it really make sense to have 1PC as an option? they don't offer any consistency guarantees so async API + non tx do about the same thing > 5. Configuration changes > - remove (deprecate first) {{write-skew}} attribute. it will be enabled automatically when needed to keep the data consistent > - -remove {{eager-locking-single-node}}. deprecated since 5.1- (DONE) > - remove {{transaction-protocol}} and add {{TOTAL_ORDER}} to {{locking-mode}}. Since total order is an alternative, it makes more sense to be in the locking mode than in the separate attributed. > - -remove {{eager-locking}}. deprecated since 5.1- (DONE) > - move {{isolation-level}} to {{<transaction>}}. it only makes sense for transactional caches. > - remove {{single-phase-auto-commit}} ?? it is 1PC for auto-commit transactions. does it make sense to have it? it doesn't provide any guarantees. > 6. Internal changes > - remove list of {{WriteCommand}} and keep a map between {{key}} and {{new-value, new-metadata and version-read}}. A {{null}} value means a remove operation. > 7. Create a single {{XaResource}}/{{Synchronization}} per cache-manager instead of per cache. > 8. For implicit transaction and {{auto-commit=true}}, if the transaction fails to commit, it can be retried until succeed. This will make the conditional operation to return a valid return value. Possible problem with retry is when a partition happens and it may fail the transaction forever. > - note: conditional operations that return {{true}} or {{false}} doesn't need to retry the transaction. They can return {{false}} when the transaction fails. > [1] http://markmail.org/thread/a7fjko4dyejxqgdy > [2] https://github.com/infinispan/infinispan/pull/2177 > [3] http://infinispan.markmail.org/thread/nl2bs7rjvayjcybv > [4] http://infinispan.markmail.org/thread/vbg6g4otu7djazbc -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2017