[JBoss JIRA] (ISPN-7405) DMR operation register-proto-schemas fails with NPE if the proto file has syntax errors
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-7405?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-7405:
-----------------------------------------------
Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1428027|https://bugzilla.redhat.com/show_bug.cgi?id=1428027] from MODIFIED to ON_QA
> 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
> Assignee: Dan Berindei
> Priority: Blocker
> Fix For: 9.0.0.CR2
>
> 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, 6 months
[JBoss JIRA] (ISPN-7884) StackOverflowException caused by GetAllCommand
by Radim Vansa (JIRA)
Radim Vansa created ISPN-7884:
---------------------------------
Summary: StackOverflowException caused by GetAllCommand
Key: ISPN-7884
URL: https://issues.jboss.org/browse/ISPN-7884
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 9.1.0.Alpha1
Reporter: Radim Vansa
Assignee: Radim Vansa
GetAllCommand in BaseDistributionInterceptor handles all unsuccessful responses by throwing OutdatedTopologyException.
BaseStateTransferInterceptor assumes that this is due to UnsureResponse in a scenario where it should be possible to retry the command immediately.
If this occurs due to CacheNotFoundResponse (node being suspected) but before the availability mode is updated/consistent hash is updated with lost segments assigned to other nodes, the command is retried in a loop up to a point where the thread hits stack overflow.
This does not affect regular cache.get() since this one throws AllOwnersLostException instead and this is treated differently in BaseStateTransferInterceptor.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 6 months
[JBoss JIRA] (ISPN-7856) Do not re-distribute the org.hibernate.search.orm module
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-7856?page=com.atlassian.jira.plugin.... ]
Ryan Emerson updated ISPN-7856:
-------------------------------
Fix Version/s: 9.1.0.Final
(was: 9.1.0.Alpha1)
> Do not re-distribute the org.hibernate.search.orm module
> --------------------------------------------------------
>
> Key: ISPN-7856
> URL: https://issues.jboss.org/browse/ISPN-7856
> Project: Infinispan
> Issue Type: Bug
> Components: Build process
> Reporter: Sanne Grinovero
> Assignee: Gustavo Fernandes
> Priority: Minor
> Fix For: 9.1.0.Final
>
>
> Infinispan's build process is currently re-publishing the Hibernate Search modules as it needs to make some changes in their structure.
> However it only needs the {{hibernate-search-engine}} component and some other extensions, it should not re-publish the {{org.hibernate.search.orm}} WildFly module as this is unnecessary and can confuse people about the intended purpose of these modules.
> Side note: do we still need to re-distributed these modules at all? We did some improvements in the build, I wonder if we could avoid this dodgy process.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 6 months