March 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-6976) Log#iterationClosed should not use INFO level logging

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6976?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6976: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Log#iterationClosed should not use INFO level logging > ----------------------------------------------------- > > Key: ISPN-6976 > URL: https://issues.jboss.org/browse/ISPN-6976 > Project: Infinispan > Issue Type: Enhancement > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Minor > Fix For: 9.0.0.Final > > > I'm seeing lots of: > INFO RemoteCloseableIterator:69 - ISPN004046: Successfully closed remote iterator 'ae8525ce-a1f2-4dd8-b365-cce77af47656' > This is better suited for DEBUG level as it refers to normal operations. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7628) Administration console - the cluster status doesn't reflect "reload-required" state of its nodes

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-7628?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-7628: ------------------------------- Status: Open (was: New) > Administration console - the cluster status doesn't reflect "reload-required" state of its nodes > ------------------------------------------------------------------------------------------------ > > Key: ISPN-7628 > URL: https://issues.jboss.org/browse/ISPN-7628 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 9.0.0.CR2 > Reporter: Roman Macor > Assignee: Vladimir Blagojevic > > The cluster has "Started" status even though all of its nodes have "reload-required" status. > Expected result: > The cluster status should also be "reload-required" > Another suggestion: > "Reload" action should be available from the cluster so that the user doesn't need to perform this action on individual nodes (there could be hundreds of them ) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7628) Administration console - the cluster status doesn't reflect "reload-required" state of its nodes

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-7628?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-7628: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan-management-console/pull/199 > Administration console - the cluster status doesn't reflect "reload-required" state of its nodes > ------------------------------------------------------------------------------------------------ > > Key: ISPN-7628 > URL: https://issues.jboss.org/browse/ISPN-7628 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 9.0.0.CR2 > Reporter: Roman Macor > Assignee: Vladimir Blagojevic > > The cluster has "Started" status even though all of its nodes have "reload-required" status. > Expected result: > The cluster status should also be "reload-required" > Another suggestion: > "Reload" action should be available from the cluster so that the user doesn't need to perform this action on individual nodes (there could be hundreds of them ) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6976) Log#iterationClosed should not use INFO level logging

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-6976?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-6976: ---------------------------------- Status: Open (was: New) > Log#iterationClosed should not use INFO level logging > ----------------------------------------------------- > > Key: ISPN-6976 > URL: https://issues.jboss.org/browse/ISPN-6976 > Project: Infinispan > Issue Type: Enhancement > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Minor > Fix For: 9.0.0.Final > > > I'm seeing lots of: > INFO RemoteCloseableIterator:69 - ISPN004046: Successfully closed remote iterator 'ae8525ce-a1f2-4dd8-b365-cce77af47656' > This is better suited for DEBUG level as it refers to normal operations. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6976) Log#iterationClosed should not use INFO level logging

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-6976?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-6976: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5002 > Log#iterationClosed should not use INFO level logging > ----------------------------------------------------- > > Key: ISPN-6976 > URL: https://issues.jboss.org/browse/ISPN-6976 > Project: Infinispan > Issue Type: Enhancement > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Minor > Fix For: 9.0.0.Final > > > I'm seeing lots of: > INFO RemoteCloseableIterator:69 - ISPN004046: Successfully closed remote iterator 'ae8525ce-a1f2-4dd8-b365-cce77af47656' > This is better suited for DEBUG level as it refers to normal operations. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6976) Log#iterationClosed should not use INFO level logging

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-6976?page=com.atlassian.jira.plugin.... ] Sanne Grinovero reassigned ISPN-6976: ------------------------------------- Assignee: Sanne Grinovero > Log#iterationClosed should not use INFO level logging > ----------------------------------------------------- > > Key: ISPN-6976 > URL: https://issues.jboss.org/browse/ISPN-6976 > Project: Infinispan > Issue Type: Enhancement > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Minor > Fix For: 9.0.0.Final > > > I'm seeing lots of: > INFO RemoteCloseableIterator:69 - ISPN004046: Successfully closed remote iterator 'ae8525ce-a1f2-4dd8-b365-cce77af47656' > This is better suited for DEBUG level as it refers to normal operations. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6029) DDL for JDBC store tables should never allow null

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-6029?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-6029: ------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/4957, https://github.com/infinispan/infinispan/pull/5001 (was: https://github.com/infinispan/infinispan/pull/4957) > DDL for JDBC store tables should never allow null > ------------------------------------------------- > > Key: ISPN-6029 > URL: https://issues.jboss.org/browse/ISPN-6029 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 8.1.0.Final, 8.2.0.Final, 8.0.2.Final, 9.0.0.CR2 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 9.0.0.CR4 > > > The DDL for jdbc persistent stores creates a 3 column table, where only the primary key is not null. However, both the string-based and binary-based cache stores require non-null values for the data column and timestamp column. These columns should not allow null values. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6029) DDL for JDBC store tables should never allow null

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-6029?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-6029: ------------------------------- Fix Version/s: 9.0.0.CR4 > DDL for JDBC store tables should never allow null > ------------------------------------------------- > > Key: ISPN-6029 > URL: https://issues.jboss.org/browse/ISPN-6029 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 8.1.0.Final, 8.2.0.Final, 8.0.2.Final, 9.0.0.CR2 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 9.0.0.CR4 > > > The DDL for jdbc persistent stores creates a 3 column table, where only the primary key is not null. However, both the string-based and binary-based cache stores require non-null values for the data column and timestamp column. These columns should not allow null values. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[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)

7 years, 9 months

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)

7 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2017