December 2014 - infinispan-issues

[JBoss JIRA] (ISPN-4359) Provide an annotation driven way of declaring protobuf metadata

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-4359?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-4359: -------------------------------- Git Pull Request: https://github.com/infinispan/protostream/pull/14, https://github.com/infinispan/infinispan/pull/3177 (was: https://github.com/infinispan/protostream/pull/14) > Provide an annotation driven way of declaring protobuf metadata > --------------------------------------------------------------- > > Key: ISPN-4359 > URL: https://issues.jboss.org/browse/ISPN-4359 > Project: Infinispan > Issue Type: Feature Request > Components: Marshalling > Affects Versions: 7.0.0.Alpha4 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: jdg > Fix For: 7.1.0.Beta1 > > > The main goal of this is to simply marshalling of java objects to protobuf using the Protostream library. > Instead of providing a Protostream MessageMarshaller implementation and a proto schema file it would be nice to have an alternative way of just adding minimal annotations to a Java class (and its fields) to assist on the fly generation (via reflection) of the proto schema. The Protostream library should also infer the marshaller so it would not require a manually implemented one. The annotation should require minimal info (tag number) and the rest should be inferred based on common sense defaults (protobuf type, java collection type, collection element type ...) but should be possible to override. The auto-generated schema should be available to users and they should be able then to use it as reference if they need it to implement domain model classes and marshallers for other languages. > The user should still be able to specify a manually created schema (besides the annotated classes) and in that case the Protostream library should check the auto-inferred schema against the provided one and ensure they match. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5071) No rebalance enabled and suspended messages logged

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5071?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5071: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1152943|https://bugzilla.redhat.com/show_bug.cgi?id=1152943] from POST to MODIFIED > No rebalance enabled and suspended messages logged > -------------------------------------------------- > > Key: ISPN-5071 > URL: https://issues.jboss.org/browse/ISPN-5071 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 7.0.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 7.1.0.Beta1 > > > {{DefaultRebalancePolicy}} was logging a message at debug level when rebalance was enabled or disabled. We should add a similar message back in {{ClusterTopologyManagerImpl.setRebalancingEnabled}}. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5000) Cleanup rebalance confirmation collector when node is not coord

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5000?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5000: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1166243|https://bugzilla.redhat.com/show_bug.cgi?id=1166243] from POST to MODIFIED > Cleanup rebalance confirmation collector when node is not coord > --------------------------------------------------------------- > > Key: ISPN-5000 > URL: https://issues.jboss.org/browse/ISPN-5000 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Affects Versions: 7.0.1.Final > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.1.0.Beta1, 7.0.3.Final > > > The rebalance confirmation collector is not properly cleared when node becomes non-coordinator. Therefore, when it becomes coordinator, it does not start the rebalance. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5094) Deprecate org.infinispan.protostream.Message interface and introduce a more sensible way of handling unknown fields

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5094?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-5094: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.1.0.Beta1 Resolution: Done Integrated .in master. > Deprecate org.infinispan.protostream.Message interface and introduce a more sensible way of handling unknown fields > ------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-5094 > URL: https://issues.jboss.org/browse/ISPN-5094 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.1.0.Beta1 > > > org.infinispan.protostream.Message mechanism for supporting unknown fields is a bit too intrusive because it forces users to implement our interface in their domain model classes. > A better approach would be to have a similar interface implemented by the marshaller object instead. > {code} > public interface UnknownFieldSetHandler<T> { > UnknownFieldSet getUnknownFieldSet(T message); > void setUnknownFieldSet(T message, UnknownFieldSet unknownFieldSet); > } > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4935) Quickstarts: Remote query not working

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-4935?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-4935: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Integrated in master. > Quickstarts: Remote query not working > ------------------------------------- > > Key: ISPN-4935 > URL: https://issues.jboss.org/browse/ISPN-4935 > Project: Infinispan > Issue Type: Bug > Components: Demos and Tutorials > Affects Versions: 7.0.0.CR2 > Reporter: Jiří Holuša > Assignee: Adrian Nistor > Fix For: 7.1.0.Beta1 > > > When testing remote query quickstarts I found out it's not working anymore. > After setting up the server (as wrote in README file), building it (mvn clean package) and running it (mvn exec:java) I get following exception: > Caused by: java.lang.NoSuchMethodException: org.infinispan.query.remote.ProtobufMetadataManager.registerProtofile([B) > at java.lang.Class.getMethod(Class.java:1665) > at org.infinispan.jmx.ResourceDMBean.invoke(ResourceDMBean.java:268) > I think this is related to https://issues.jboss.org/browse/ISPN-3480 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4884) Deployment scanner should be enabled to allow filter/converter jar deployment

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4884?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4884: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1156397|https://bugzilla.redhat.com/show_bug.cgi?id=1156397] from MODIFIED to POST > Deployment scanner should be enabled to allow filter/converter jar deployment > ----------------------------------------------------------------------------- > > Key: ISPN-4884 > URL: https://issues.jboss.org/browse/ISPN-4884 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Affects Versions: 7.0.0.CR2 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Critical > Fix For: 7.0.0.Final > > > When we want to copy JARS and deploy it on JDG server in standalone/clustered.xml is no deployment-scanner element defined. It should be added when server is built > Steps to Reproduce: > 1. cp filter-converter.jar infinispan-server-7.0.0.CR2/standalone/deployments/ > 2. look at console output of server > 3. check if there is no output from deployment scanner > Current results: not output from deployment scanner, because it is not enabled > Expected results: we should see following output in console log > JBAS015012: Started FileSystemDeploymentService for directory /home/infinispan-server-7.0.0.CR2/standalone/deployments > JBAS015876: Starting deployment of "filter-converter.jar" (runtime-name: "filter-converter.jar") -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4359) Provide an annotation driven way of declaring protobuf metadata

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4359?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4359: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1172646|https://bugzilla.redhat.com/show_bug.cgi?id=1172646] from ASSIGNED to MODIFIED > Provide an annotation driven way of declaring protobuf metadata > --------------------------------------------------------------- > > Key: ISPN-4359 > URL: https://issues.jboss.org/browse/ISPN-4359 > Project: Infinispan > Issue Type: Feature Request > Components: Marshalling > Affects Versions: 7.0.0.Alpha4 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: jdg > Fix For: 7.1.0.Beta1 > > > The main goal of this is to simply marshalling of java objects to protobuf using the Protostream library. > Instead of providing a Protostream MessageMarshaller implementation and a proto schema file it would be nice to have an alternative way of just adding minimal annotations to a Java class (and its fields) to assist on the fly generation (via reflection) of the proto schema. The Protostream library should also infer the marshaller so it would not require a manually implemented one. The annotation should require minimal info (tag number) and the rest should be inferred based on common sense defaults (protobuf type, java collection type, collection element type ...) but should be possible to override. The auto-generated schema should be available to users and they should be able then to use it as reference if they need it to implement domain model classes and marshallers for other languages. > The user should still be able to specify a manually created schema (besides the annotated classes) and in that case the Protostream library should check the auto-inferred schema against the provided one and ensure they match. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5104) Infinite loop in TransactionAwareCloseableIterator when iterating through cache...

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5104?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5104: ----------------------------------------------- William Burns <wburns(a)redhat.com> changed the Status of [bug 1176910|https://bugzilla.redhat.com/show_bug.cgi?id=1176910] from NEW to POST > Infinite loop in TransactionAwareCloseableIterator when iterating through cache... > ---------------------------------------------------------------------------------- > > Key: ISPN-5104 > URL: https://issues.jboss.org/browse/ISPN-5104 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 7.0.2.Final > Reporter: Christian Niessner > Assignee: William Burns > Fix For: 7.1.0.Beta1, 7.0.3.Final > > > Hi, > i have some testing code that iterates through a cache and validates all data in this cache for consistency. > The reduced code is: > TransactionManager tm = cache.getAdvancedCache().getTransactionManager(); > tm.begin(); > try { > for (Entry<Object,Object> entry : metadataCache.entrySet()) { > // validation code omitted... > } > } finally { > tm.commit(); > } > In some circumstances the iteration starts returning the same Entry every time. I stepped into the code and the value is returned from: > https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o... > This code block is commented with: > "// We do a last check to make sure no additional values were added to our context while iterating" > And for me it seems that the value returned here never gets added to the "seenContextKeys" Set and so the iterator is always returning the same key. > Maybe a simple "seenContextKeys.add(lookedUpEntry.getKey())" next to Line 70 would fix this issue. Maybe even a 'break' could make sense here because is there the need to walk through the entire list if we have found a candidate? -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4884) Deployment scanner should be enabled to allow filter/converter jar deployment

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4884?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4884: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1156397|https://bugzilla.redhat.com/show_bug.cgi?id=1156397] from POST to MODIFIED > Deployment scanner should be enabled to allow filter/converter jar deployment > ----------------------------------------------------------------------------- > > Key: ISPN-4884 > URL: https://issues.jboss.org/browse/ISPN-4884 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Affects Versions: 7.0.0.CR2 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Critical > Fix For: 7.0.0.Final > > > When we want to copy JARS and deploy it on JDG server in standalone/clustered.xml is no deployment-scanner element defined. It should be added when server is built > Steps to Reproduce: > 1. cp filter-converter.jar infinispan-server-7.0.0.CR2/standalone/deployments/ > 2. look at console output of server > 3. check if there is no output from deployment scanner > Current results: not output from deployment scanner, because it is not enabled > Expected results: we should see following output in console log > JBAS015012: Started FileSystemDeploymentService for directory /home/infinispan-server-7.0.0.CR2/standalone/deployments > JBAS015876: Starting deployment of "filter-converter.jar" (runtime-name: "filter-converter.jar") -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5104) Infinite loop in TransactionAwareCloseableIterator when iterating through cache...

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5104?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-5104: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1176910 > Infinite loop in TransactionAwareCloseableIterator when iterating through cache... > ---------------------------------------------------------------------------------- > > Key: ISPN-5104 > URL: https://issues.jboss.org/browse/ISPN-5104 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 7.0.2.Final > Reporter: Christian Niessner > Assignee: William Burns > Fix For: 7.1.0.Beta1, 7.0.3.Final > > > Hi, > i have some testing code that iterates through a cache and validates all data in this cache for consistency. > The reduced code is: > TransactionManager tm = cache.getAdvancedCache().getTransactionManager(); > tm.begin(); > try { > for (Entry<Object,Object> entry : metadataCache.entrySet()) { > // validation code omitted... > } > } finally { > tm.commit(); > } > In some circumstances the iteration starts returning the same Entry every time. I stepped into the code and the value is returned from: > https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o... > This code block is commented with: > "// We do a last check to make sure no additional values were added to our context while iterating" > And for me it seems that the value returned here never gets added to the "seenContextKeys" Set and so the iterator is always returning the same key. > Maybe a simple "seenContextKeys.add(lookedUpEntry.getKey())" next to Line 70 would fix this issue. Maybe even a 'break' could make sense here because is there the need to walk through the entire list if we have found a candidate? -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues December 2014