[JBoss JIRA] (ISPN-7405) DMR operation register-proto-schemas fails with NPE if the proto file has syntax errors
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-7405?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo commented on ISPN-7405:
-----------------------------------
[~anistor], I've digging a little bit in it. This are my findings:
In Alpha4, the operation fails in runtime with {{java.lang.IllegalStateException: Syntax error in myFileWithSyntaxErrors.proto at 1:7: unexpected label: kaboom}}.
However, in Beta1, things changed. When it fails, it started to invoke {{ProgressCallback.handleError}}. However, this method tries to store in the cache and creates a put command with {{null}} {{Metadata}}. When the cache-store tries to fetch the lifespan, the metadata is null and the NPE is thrown.
I've made a patch for it [1] and it seems to work based on your description. Pick it up and try with your tests.
[1] https://github.com/pruivo/infinispan/tree/t_7405
> DMR operation register-proto-schemas fails with NPE if the proto file has syntax errors
> ---------------------------------------------------------------------------------------
>
> Key: ISPN-7405
> URL: https://issues.jboss.org/browse/ISPN-7405
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Querying, Server
> Affects Versions: 9.0.0.Beta2
> Reporter: Adrian Nistor
> Priority: Blocker
> Fix For: 9.0.0.CR1
>
> Attachments: error.log
>
>
> Start an infinispan server and run the following CLI command:
> ./bin/ispn-cli.sh -c '/subsystem=datagrid-infinispan/cache-container=local:register-proto-schemas(file-names=[myFileWithSyntaxErrors.proto], file-contents=[kaboom])'
> since the file has syntax errors it should still be placed in the ___protobuf_metadata cache and a myFileWithSyntaxErrors.proto.errors key should also be created. No exception should be thrown. Currently no key is written in cache and the NPE from the attached log happens.
> When registering a proper file without syntax errors this works correctly.
> The problem disappears if I disable global state persistence, so the cachestore seems to play a role in this.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 11 months
[JBoss JIRA] (ISPN-7370) Administration console - configuration of cache store is broken
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-7370?page=com.atlassian.jira.plugin.... ]
Ryan Emerson reassigned ISPN-7370:
----------------------------------
Assignee: Ryan Emerson (was: Vladimir Blagojevic)
> Administration console - configuration of cache store is broken
> ---------------------------------------------------------------
>
> Key: ISPN-7370
> URL: https://issues.jboss.org/browse/ISPN-7370
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 9.0.0.Beta1
> Reporter: Roman Macor
> Assignee: Ryan Emerson
> Fix For: 9.0.0.CR1
>
> Attachments: Screenshot from 2017-01-19.png
>
>
> Click on cache container -> cache -> configuration -> Store -> Select store type e.g. Binary keyed JDBC store
> Issues:
> some property names are displayed like this: {{$ctrl.resolveFieldName()}}
> ... links (for Write Behind for example) are not working
> Please see the attached screenshot for details.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 11 months
[JBoss JIRA] (ISPN-7228) Administration console - creating wrong schema doesn't show error message
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-7228?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-7228:
-------------------------------------
[~vblagojevic] If you are happy with the fix for https://issues.jboss.org/browse/ISPN-7402 just merge it and disable global-state as a workaround to test for now.
> Administration console - creating wrong schema doesn't show error message
> -------------------------------------------------------------------------
>
> Key: ISPN-7228
> URL: https://issues.jboss.org/browse/ISPN-7228
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 9.0.0.Alpha4
> Reporter: Roman Macor
> Assignee: Vladimir Blagojevic
> Priority: Minor
> Attachments: ISPN-7228.txt
>
>
> Click on cache container -> Configuration -> Schemas -> Add -> Fill in incorrect scheme: (schema name: wrong_schema, Schema: nonsense)
> Result: The dialog is closed and no schema is created.
> Expected message:
> Error There has been an error executing the operation: DGISPN0118: Failed to invoke operation: org.infinispan.protostream.DescriptorParserException: java.lang.IllegalStateException: Syntax error in nonsense.proto at 1:9: unexpected label: nonsense
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 11 months
[JBoss JIRA] (ISPN-7413) Expose page sized chunked marshalled buffers
by Galder Zamarreño (JIRA)
Galder Zamarreño created ISPN-7413:
--------------------------------------
Summary: Expose page sized chunked marshalled buffers
Key: ISPN-7413
URL: https://issues.jboss.org/browse/ISPN-7413
Project: Infinispan
Issue Type: Enhancement
Components: Core, Marshalling
Reporter: Galder Zamarreño
Instead of trying to predict what is the buffer size for a particular type, it would make more sense to take advantage of the fact that eventually, the marshalled buffers are sent over the network or stored in some sort of persistence layer and hence marshalled payloads might be fragmented to fit the system. So, the marshalling layer could return a collection of buffers, according to the adequate page size.
These are the benefits of such approach:
* No longer need to keep track of buffer sizes per type. Simply configure page size and let the marshaller split the marshalled payload in pages.
* JGroups could take advantage of these pages avoiding the need to split them up when sending them across to other nodes (FRAG/2 would only need to fragment JGroups metadata, if necessary). The marshaller would already have done the job for it.
* Having a page structure for marshalling values would more easily fit with the off-heap organization, reducing compaction needs.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 11 months
[JBoss JIRA] (ISPN-7412) Expand usage of MarshallUtil for marshalling collections internally
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-7412?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-7412:
----------------------------------------
Benefits:
* Less externalizers means less code to maintain and smaller lookup tables when trying to figure out how to marshall a particular type.
* By not relying on `writeObject`, table lookups are avoided making marshalling code faster to run.
> Expand usage of MarshallUtil for marshalling collections internally
> -------------------------------------------------------------------
>
> Key: ISPN-7412
> URL: https://issues.jboss.org/browse/ISPN-7412
> Project: Infinispan
> Issue Type: Task
> Components: Core, Marshalling
> Reporter: Galder Zamarreño
>
> Some externalizers might still rely on calling writeObject() when trying to marshall collections. Make sure they use MarshallUtil instead to avoid extra cost.
> Ideally, this should enable us to get rid of collection based externalizers in our internal externalizer collection. Although this might only achievable once user marshaller is in place (ISPN-7409)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 11 months