[JBoss JIRA] (ISPN-8980) High concurrency : Infinispan Directory Provider: Lucene : Error loading metadata for index file
by Debashish Bharali (JIRA)
[ https://issues.jboss.org/browse/ISPN-8980?page=com.atlassian.jira.plugin.... ]
Debashish Bharali updated ISPN-8980:
------------------------------------
Attachment: JoiningNode_N2.zip
> High concurrency : Infinispan Directory Provider: Lucene : Error loading metadata for index file
> ------------------------------------------------------------------------------------------------
>
> Key: ISPN-8980
> URL: https://issues.jboss.org/browse/ISPN-8980
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 8.2.5.Final
> Reporter: Debashish Bharali
> Assignee: Gustavo Fernandes
> Priority: Critical
> Attachments: JoiningNode_N2.zip, OriginalNode_N1.zip, SysOutLogs.txt, neutrino-hibernate-search-worker-jgroups.xml, neutrino-hibernatesearch-infinispan.xml
>
>
> During high concurrency of action, we are getting *{color:red}'Error loading metadata for index file'{color}* even in *{color:red}Non-Clustered{color}* env.
> *Hibernate Search Indexes (Lucene Indexes) - 5.7.0.Final*
> *Infinispan - 8.2.5.Final*
> *infinispan-directory-provider-8.2.5.Final*
> *jgroups-3.6.7.Final*
> *Worker Backend : JGroups*
> *Worker Execution: Sync*
> *write_metadata_async: false (implicitly)*
> *Note:* Currently we are on Non-Clustered env. We are moving to Clustered Env within few days.
> On analyzing the code, and putting some additional SYSOUT loggers into FileListOperations and DirectoryImplementor classes, we have established the following points:
> # This is happening during high concurrency on non-clustered env.
> # One thread *'T1'* is deleting a segment and segment name *'SEG1'* from the *'FileListCacheKey'* list* stored in MetaDatacache*.
> # Concurrently, at the same time, another thread *'T2'* is looping through the FileList ['copy list' from MetadataCache - for -FileListCacheKey - provided by toArray method of *FileListOperations* (changes also being done in the corresponding original list by T1 thread) ].
> # *'T2'* is calling open input method on each segment name - getting corresponding Metadata segment from *MetadataCache*.
> # However, for *'T2'*, the *'copy list'* still contains the name of segment *'SEG1'*.
> # So while looping through the list, *'T2'* tries to get Segment from MetadataCache for segment name *'SEG1'*.
> # But at this instant, *segment* corresponding to segment name *'SEG1'*, has been already removed from *MetadataCache* by *'T1'*.
> # This results in *'java.io.FileNotFoundException: Error loading metadata for index file'* for segment name *'SEG1'*
> # As mentioned earlier, this happens more often during high concurrency.
> *{color:red}On a standalone server (non-clustered), we are getting below error intermittently:{color}*
> Full Stack trace:
> 2018-03-19 17:29:11,938 ERROR [Hibernate Search sync consumer thread for index com.nucleus.integration.ws.server.globalcustomer.entity.GlobalCustomer] o.h.s.e.i.LogErrorHandler [LogErrorHandler.java:69]
> *{color:red}HSEARCH000058: Exception occurred java.io.FileNotFoundException: Error loading metadata for index file{color}*: M|segments_w6|com.nucleus.integration.ws.server.globalcustomer.entity.GlobalCustomer|-1
> Primary Failure:
> Entity com.nucleus.integration.ws.server.globalcustomer.entity.GlobalCustomer Id 1649990024999813056 Work Type org.hibernate.search.backend.AddLuceneWork
> java.io.FileNotFoundException: Error loading metadata for index file: M|segments_w6|com.nucleus.integration.ws.server.globalcustomer.entity.GlobalCustomer|-1
> at org.infinispan.lucene.impl.DirectoryImplementor.openInput(DirectoryImplementor.java:138) ~[infinispan-lucene-directory-8.2.5.Final.jar:8.2.5.Final]
> at org.infinispan.lucene.impl.DirectoryLucene.openInput(DirectoryLucene.java:102) ~[infinispan-lucene-directory-8.2.5.Final.jar:8.2.5.Final]
> at org.apache.lucene.store.Directory.openChecksumInput(Directory.java:109) ~[lucene-core-5.5.4.jar:5.5.4 31012120ebbd93744753eb37f1dbc5e654628291 - jpountz - 2017-02-08 19:08:03]
> at org.apache.lucene.index.SegmentInfos.readCommit(SegmentInfos.java:294) ~[lucene-core-5.5.4.jar:5.5.4 31012120ebbd93744753eb37f1dbc5e654628291 - jpountz - 2017-02-08 19:08:03]
> at org.apache.lucene.index.IndexFileDeleter.<init>(IndexFileDeleter.java:171) ~[lucene-core-5.5.4.jar:5.5.4 31012120ebbd93744753eb37f1dbc5e654628291 - jpountz - 2017-02-08 19:08:03]
> at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:949) ~[lucene-core-5.5.4.jar:5.5.4 31012120ebbd93744753eb37f1dbc5e654628291 - jpountz - 2017-02-08 19:08:03]
> at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.createNewIndexWriter(IndexWriterHolder.java:126) ~[hibernate-search-engine-5.7.0.Final.jar:5.7.0.Final]
> at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.getIndexWriter(IndexWriterHolder.java:92) ~[hibernate-search-engine-5.7.0.Final.jar:5.7.0.Final]
> at org.hibernate.search.backend.impl.lucene.AbstractCommitPolicy.getIndexWriter(AbstractCommitPolicy.java:33) ~[hibernate-search-engine-5.7.0.Final.jar:5.7.0.Final]
> at org.hibernate.search.backend.impl.lucene.SharedIndexCommitPolicy.getIndexWriter(SharedIndexCommitPolicy.java:77) ~[hibernate-search-engine-5.7.0.Final.jar:5.7.0.Final]
> at org.hibernate.search.backend.impl.lucene.SharedIndexWorkspaceImpl.getIndexWriter(SharedIndexWorkspaceImpl.java:36) ~[hibernate-search-engine-5.7.0.Final.jar:5.7.0.Final]
> at org.hibernate.search.backend.impl.lucene.AbstractWorkspaceImpl.getIndexWriterDelegate(AbstractWorkspaceImpl.java:203) [hibernate-search-engine-5.7.0.Final.jar:5.7.0.Final]
> at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask.applyUpdates(LuceneBackendQueueTask.java:81) [hibernate-search-engine-5.7.0.Final.jar:5.7.0.Final]
> at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask.run(LuceneBackendQueueTask.java:46) [hibernate-search-engine-5.7.0.Final.jar:5.7.0.Final]
> at org.hibernate.search.backend.impl.lucene.SyncWorkProcessor$Consumer.applyChangesets(SyncWorkProcessor.java:165) [hibernate-search-engine-5.7.0.Final.jar:5.7.0.Final]
> at org.hibernate.search.backend.impl.lucene.SyncWorkProcessor$Consumer.run(SyncWorkProcessor.java:151) [hibernate-search-engine-5.7.0.Final.jar:5.7.0.Final]
> at java.lang.Thread.run(Thread.java:785) [na:1.8.0-internal]
> *As per our understanding, this issue should not come in {color:red}'non-clustered'{color} env. Also it should not arise when worker execution is {color:red}'sync'{color}.*
> *We have debugged the code, and confirmed that the value for {color:red}'write_metadata_async'{color} is coming as 'false' only (as expected).*
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 9 months
[JBoss JIRA] (ISPN-9068) Indexer throws exception in cluster mode
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-9068?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-9068:
------------------------------------
Fix Version/s: 9.2.2.Final
9.3.0.Alpha1
> Indexer throws exception in cluster mode
> ----------------------------------------
>
> Key: ISPN-9068
> URL: https://issues.jboss.org/browse/ISPN-9068
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.2.1.Final
> Reporter: Sergey Chernolyas
> Assignee: Gustavo Fernandes
> Priority: Critical
> Fix For: 9.2.2.Final, 9.3.0.Alpha1
>
> Attachments: re_clustered_rocksdb.xml, re_entities.proto
>
>
> I have a cluster that contains two hosts.
> Also one cache have a indexing.
> Then I try add entity (see entity News in attached proto) to the cache, I take exception:
> __________
> 2018-04-11 21:17:54,695 ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (jgroups-17,server2) ISPN000136: Error executing command PutKeyValueCommand, writing keys [WrappedByteArray{bytes=[B0x4A24303030303030..[38], hashCode=61362266}]: org.hibernate.search.exception.SearchException: Unable to perform work. Entity Class is not @Indexed nor hosts @ContainedIn: org.infinispan.query.backend.QueryInterceptor$1
> at org.hibernate.search.backend.impl.PerTransactionWorker.performWork(PerTransactionWorker.java:63)
> at org.infinispan.query.backend.QueryInterceptor.performSearchWorks(QueryInterceptor.java:383)
> at org.infinispan.query.backend.QueryInterceptor.removeFromIndexes(QueryInterceptor.java:337)
> at org.infinispan.query.backend.QueryInterceptor.processChange(QueryInterceptor.java:448)
> at org.infinispan.query.backend.QueryInterceptor.lambda$handleDataWriteCommand$0(QueryInterceptor.java:184)
> at org.infinispan.interceptors.InvocationSuccessAction.apply(InvocationSuccessAction.java:19)
> at org.infinispan.interceptors.impl.QueueAsyncInvocationStage.invokeQueuedHandlers(QueueAsyncInvocationStage.java:118)
> at org.infinispan.interceptors.impl.QueueAsyncInvocationStage.accept(QueueAsyncInvocationStage.java:81)
> at org.infinispan.interceptors.impl.QueueAsyncInvocationStage.accept(QueueAsyncInvocationStage.java:30)
> at java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:760)
> at java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:736)
> at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
> at org.infinispan.remoting.transport.AbstractRequest.complete(AbstractRequest.java:66)
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onResponse(MultiTargetRequest.java:102)
> at org.infinispan.remoting.transport.impl.RequestRepository.addResponse(RequestRepository.java:53)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.processResponse(JGroupsTransport.java:1304)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.processMessage(JGroupsTransport.java:1207)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.access$200(JGroupsTransport.java:123)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport$ChannelCallbacks.receive(JGroupsTransport.java:1342)
> at org.jgroups.JChannel.up(JChannel.java:819)
> at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:134)
> at org.jgroups.stack.Protocol.up(Protocol.java:340)
> at org.jgroups.protocols.FORK.up(FORK.java:134)
> at org.jgroups.protocols.FRAG3.up(FRAG3.java:171)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:343)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:343)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:864)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:240)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1002)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:728)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:383)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:600)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:119)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:199)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:252)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:276)
> at org.jgroups.protocols.Discovery.up(Discovery.java:267)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1248)
> at org.jgroups.util.SubmitToThreadPool$SingleMessageHandler.run(SubmitToThreadPool.java:87)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> _____
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 9 months
[JBoss JIRA] (ISPN-9073) NPE with unauthorized CORS preflight request
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-9073?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-9073:
------------------------------------
Status: Open (was: New)
> NPE with unauthorized CORS preflight request
> --------------------------------------------
>
> Key: ISPN-9073
> URL: https://issues.jboss.org/browse/ISPN-9073
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.2.1.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
>
> This could happen if the browser does a pre-flight request with an "Origin" header which is not part of the authorized list of origins.
> {noformat}
> 2:16:19,514 ERROR [org.infinispan.rest.Http20RequestHandler] (REST-ServerWorker-5-12) ISPN012006: Uncaught exception in the pipeline: java.lang.NullPointerException
> at org.infinispan.rest.cors.CorsHandler.setOrigin(CorsHandler.java:126)
> at org.infinispan.rest.cors.CorsHandler.handlePreflight(CorsHandler.java:80)
> at org.infinispan.rest.cors.CorsHandler.channelRead(CorsHandler.java:67)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> at io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.fireChannelRead(CombinedChannelDuplexHandler.java:438)
> at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:310)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:284)
> at io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:253)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> at io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86)
> at org.infinispan.server.core.transport.StatsChannelHandler.channelRead(StatsChannelHandler.java:26)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 9 months
[JBoss JIRA] (ISPN-9073) NPE with unauthorized CORS preflight request
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-9073?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-9073:
------------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/5920
> NPE with unauthorized CORS preflight request
> --------------------------------------------
>
> Key: ISPN-9073
> URL: https://issues.jboss.org/browse/ISPN-9073
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.2.1.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
>
> This could happen if the browser does a pre-flight request with an "Origin" header which is not part of the authorized list of origins.
> {noformat}
> 2:16:19,514 ERROR [org.infinispan.rest.Http20RequestHandler] (REST-ServerWorker-5-12) ISPN012006: Uncaught exception in the pipeline: java.lang.NullPointerException
> at org.infinispan.rest.cors.CorsHandler.setOrigin(CorsHandler.java:126)
> at org.infinispan.rest.cors.CorsHandler.handlePreflight(CorsHandler.java:80)
> at org.infinispan.rest.cors.CorsHandler.channelRead(CorsHandler.java:67)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> at io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.fireChannelRead(CombinedChannelDuplexHandler.java:438)
> at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:310)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:284)
> at io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:253)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> at io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86)
> at org.infinispan.server.core.transport.StatsChannelHandler.channelRead(StatsChannelHandler.java:26)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 9 months
[JBoss JIRA] (ISPN-9073) NPE with unauthorized CORS preflight request
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-9073?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-9073:
------------------------------------
Affects Version/s: 9.2.1.Final
> NPE with unauthorized CORS preflight request
> --------------------------------------------
>
> Key: ISPN-9073
> URL: https://issues.jboss.org/browse/ISPN-9073
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.2.1.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
>
> This could happen if the browser does a pre-flight request with an "Origin" header which is not part of the authorized list of origins.
> {noformat}
> 2:16:19,514 ERROR [org.infinispan.rest.Http20RequestHandler] (REST-ServerWorker-5-12) ISPN012006: Uncaught exception in the pipeline: java.lang.NullPointerException
> at org.infinispan.rest.cors.CorsHandler.setOrigin(CorsHandler.java:126)
> at org.infinispan.rest.cors.CorsHandler.handlePreflight(CorsHandler.java:80)
> at org.infinispan.rest.cors.CorsHandler.channelRead(CorsHandler.java:67)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> at io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.fireChannelRead(CombinedChannelDuplexHandler.java:438)
> at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:310)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:284)
> at io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:253)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> at io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86)
> at org.infinispan.server.core.transport.StatsChannelHandler.channelRead(StatsChannelHandler.java:26)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 9 months
[JBoss JIRA] (ISPN-9074) Internal caches should be extensible with x-site configuration
by Galder Zamarreño (JIRA)
Galder Zamarreño created ISPN-9074:
--------------------------------------
Summary: Internal caches should be extensible with x-site configuration
Key: ISPN-9074
URL: https://issues.jboss.org/browse/ISPN-9074
Project: Infinispan
Issue Type: Enhancement
Reporter: Galder Zamarreño
Example: for querying updating the protobuf metadata cache is needed. Since this is not x-site replicated, the user needs to make sure metadata gets updated in all sites whenever Infinispan instances ger started. This is a pain for the user.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 9 months
[JBoss JIRA] (ISPN-9073) NPE with unauthorized CORS preflight request
by Gustavo Fernandes (JIRA)
Gustavo Fernandes created ISPN-9073:
---------------------------------------
Summary: NPE with unauthorized CORS preflight request
Key: ISPN-9073
URL: https://issues.jboss.org/browse/ISPN-9073
Project: Infinispan
Issue Type: Bug
Reporter: Gustavo Fernandes
Assignee: Gustavo Fernandes
This could happen if the browser does a pre-flight request with an "Origin" header which is not part of the authorized list of origins.
{noformat}
2:16:19,514 ERROR [org.infinispan.rest.Http20RequestHandler] (REST-ServerWorker-5-12) ISPN012006: Uncaught exception in the pipeline: java.lang.NullPointerException
at org.infinispan.rest.cors.CorsHandler.setOrigin(CorsHandler.java:126)
at org.infinispan.rest.cors.CorsHandler.handlePreflight(CorsHandler.java:80)
at org.infinispan.rest.cors.CorsHandler.channelRead(CorsHandler.java:67)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.fireChannelRead(CombinedChannelDuplexHandler.java:438)
at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:310)
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:284)
at io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:253)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86)
at org.infinispan.server.core.transport.StatsChannelHandler.channelRead(StatsChannelHandler.java:26)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 9 months
[JBoss JIRA] (ISPN-9072) Document Protobuf annotated collection null set callbacks
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-9072?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-9072:
--------------------------------
Status: Open (was: New)
> Document Protobuf annotated collection null set callbacks
> ---------------------------------------------------------
>
> Key: ISPN-9072
> URL: https://issues.jboss.org/browse/ISPN-9072
> Project: Infinispan
> Issue Type: Task
> Components: Documentation-Query
> Affects Versions: 9.2.1.Final
> Reporter: Galder Zamarreño
> Assignee: Adrian Nistor
> Fix For: 9.3.0.Alpha1, 9.3.0.Final
>
>
> When using collection fields in Protobuf annotated classes, empty collections are marshalled into the same value as {{null}}, because Protobuf only has repeated fields and no fields is represented as {{null}}.
> This means that if you have an entity with an empty collection, when it's deserialized the collection will be null. This can be confusing for users and should be documented.
> [~anistor] had some ideas on how to improve this:
> {code}
> <anistor> I'm thinking of a way to make this easier for users that
> would prefer an empty collection being set instead of a
> null. would be possible by adding a new attribute for this in
> @ProtoField anotation
> > that'd be more predictable
> <anistor> would still not give you at deserializtion what was written
> during serialization. we do not have a null marker
> <anistor> it would just give you an empty collection if you prefer
> <anistor> instead of null
> > that option should be enabled by default
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 9 months
[JBoss JIRA] (ISPN-9072) Document Protobuf annotated collection null set callbacks
by Galder Zamarreño (JIRA)
Galder Zamarreño created ISPN-9072:
--------------------------------------
Summary: Document Protobuf annotated collection null set callbacks
Key: ISPN-9072
URL: https://issues.jboss.org/browse/ISPN-9072
Project: Infinispan
Issue Type: Task
Components: Documentation-Query
Affects Versions: 9.2.1.Final
Reporter: Galder Zamarreño
Assignee: Adrian Nistor
Fix For: 9.3.0.Alpha1, 9.3.0.Final
When using collection fields in Protobuf annotated classes, empty collections are marshalled into the same value as {{null}}, because Protobuf only has repeated fields and no fields is represented as {{null}}.
This means that if you have an entity with an empty collection, when it's deserialized the collection will be null. This can be confusing for users and should be documented.
[~anistor] had some ideas on how to improve this:
{code}
<anistor> I'm thinking of a way to make this easier for users that
would prefer an empty collection being set instead of a
null. would be possible by adding a new attribute for this in
@ProtoField anotation
> that'd be more predictable
<anistor> would still not give you at deserializtion what was written
during serialization. we do not have a null marker
<anistor> it would just give you an empty collection if you prefer
<anistor> instead of null
> that option should be enabled by default
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 9 months