[JBoss JIRA] (ISPN-7839) Pagination returns wrong results with ClusteredQueries
by Gustavo Fernandes (JIRA)
Gustavo Fernandes created ISPN-7839:
---------------------------------------
Summary: Pagination returns wrong results with ClusteredQueries
Key: ISPN-7839
URL: https://issues.jboss.org/browse/ISPN-7839
Project: Infinispan
Issue Type: Bug
Components: Embedded Querying
Affects Versions: 9.0.0.Final
Reporter: Gustavo Fernandes
When using pagination (by specifying clusteredQuery.firstResult() and/or clusteredQuery.maxResults()), the returned results are wrong.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ISPN-3795) QueryInterceptor incorrectly relies on the return value of a RemoveCommand
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-3795?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-3795:
-------------------------------------
+1 for ignoring IGNORE_RETURN_VALUE when it prevents query work, even if that means we could loose a bit of perf.
Let me remind you that continuous query also needs the previous value in order to work. That's a totally different subject, but my point is we need to accept some trade-offs when using certain features, like query, which will inevitably slow things down a bit.
We could digress into arguing if caches need to be typesafe or not, but that would still not solve the CQ issue.
> QueryInterceptor incorrectly relies on the return value of a RemoveCommand
> --------------------------------------------------------------------------
>
> Key: ISPN-3795
> URL: https://issues.jboss.org/browse/ISPN-3795
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 6.0.0.Final
> Reporter: Dan Berindei
> Assignee: Gustavo Fernandes
>
> QueryInterceptor uses the return value from RemoveCommand/ReplaceCommand to remove the value from the index.
> But both RemoveCommand and ReplaceCommand have a variant with an expected value parameter, and this variant return a boolean value instead of the removed/replaced value. In that case, the previous value won't be removed from the index.
> QueryInterceptor should probably use the previous value from the context entries to update the index instead.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ISPN-3795) QueryInterceptor incorrectly relies on the return value of a RemoveCommand
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-3795?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-3795:
-----------------------------------
[~sannegrinovero] I also prefer the more organized approach, but people love to put all their stuff in single cache... See all the trouble we've caused in ORM 2LC when removing the type info from keys. Recently I was even answering some SO questions where user wanted to put both query results and entities into single region.
> QueryInterceptor incorrectly relies on the return value of a RemoveCommand
> --------------------------------------------------------------------------
>
> Key: ISPN-3795
> URL: https://issues.jboss.org/browse/ISPN-3795
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 6.0.0.Final
> Reporter: Dan Berindei
> Assignee: Gustavo Fernandes
>
> QueryInterceptor uses the return value from RemoveCommand/ReplaceCommand to remove the value from the index.
> But both RemoveCommand and ReplaceCommand have a variant with an expected value parameter, and this variant return a boolean value instead of the removed/replaced value. In that case, the previous value won't be removed from the index.
> QueryInterceptor should probably use the previous value from the context entries to update the index instead.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ISPN-3795) QueryInterceptor incorrectly relies on the return value of a RemoveCommand
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3795?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-3795:
------------------------------------
[~sannegrinovero] just curious, how bad would it be if tracked the types in the cache and every update would purge the key from all the indexes? I.e. is there any way that could be faster than ignoring the {{IGNORE_RETURN_VALUES}} flag and returning the value to the originator?
> QueryInterceptor incorrectly relies on the return value of a RemoveCommand
> --------------------------------------------------------------------------
>
> Key: ISPN-3795
> URL: https://issues.jboss.org/browse/ISPN-3795
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 6.0.0.Final
> Reporter: Dan Berindei
> Assignee: Gustavo Fernandes
>
> QueryInterceptor uses the return value from RemoveCommand/ReplaceCommand to remove the value from the index.
> But both RemoveCommand and ReplaceCommand have a variant with an expected value parameter, and this variant return a boolean value instead of the removed/replaced value. In that case, the previous value won't be removed from the index.
> QueryInterceptor should probably use the previous value from the context entries to update the index instead.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ISPN-3795) QueryInterceptor incorrectly relies on the return value of a RemoveCommand
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-3795?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-3795:
---------------------------------------
{quote}+1 IGNORE_RETURN_VALUE should not be honoured if prevents the indexing to work.{quote}
I agree on the high level but there are some alternatives we could consider.
As far as I remember we need the previous value just because we need to know which object type is being replaced. Since we allow each "type" to be mapped to its own index, this is necessary to know which index needs to be purged of the previous value.
We have loads of (other) problems all caused by this commonality of allowing different types to be stored in the same cache; if we could implement the restriction of strongly type-safe Caches we would resolve the other problems and also no longer need this one.
Incidentally polymorphic hierarchies in Hibernate Search get indexed in the same index, so the problem is really only triggered by the user doing something like storing _unrelated_ types: we would be fine with parent/child relations. While Hibernate Search indexed parent/child objects in the index _by default_ we would also benefit from enforcing this in Infinispan.
Having strong type-safety would allow us to remove a lot more overhead as many checks currently need to be performed on a per-operation base, and the current state also requires much metadata to be computed dynamically.
> QueryInterceptor incorrectly relies on the return value of a RemoveCommand
> --------------------------------------------------------------------------
>
> Key: ISPN-3795
> URL: https://issues.jboss.org/browse/ISPN-3795
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 6.0.0.Final
> Reporter: Dan Berindei
> Assignee: Gustavo Fernandes
>
> QueryInterceptor uses the return value from RemoveCommand/ReplaceCommand to remove the value from the index.
> But both RemoveCommand and ReplaceCommand have a variant with an expected value parameter, and this variant return a boolean value instead of the removed/replaced value. In that case, the previous value won't be removed from the index.
> QueryInterceptor should probably use the previous value from the context entries to update the index instead.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ISPN-7838) JBoss Modules NPE in Domain mode
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-7838?page=com.atlassian.jira.plugin.... ]
Ryan Emerson reassigned ISPN-7838:
----------------------------------
Assignee: Tristan Tarrant
> JBoss Modules NPE in Domain mode
> --------------------------------
>
> Key: ISPN-7838
> URL: https://issues.jboss.org/browse/ISPN-7838
> Project: Infinispan
> Issue Type: Bug
> Components: Server, WildFly modules
> Affects Versions: 9.1.0.Alpha1
> Reporter: Ryan Emerson
> Assignee: Tristan Tarrant
>
> When starting the server in domain mode, the bellow errors are present on the server nodes. This seems to have been introduced by this [commit|https://github.com/infinispan/infinispan/commit/8401553ea9a64d5445...] for ISPN-7652.
> {code:java}
> 10:31:40,010 INFO [org.jboss.modules] (main) JBoss Modules version 1.5.2.Final
> 10:31:40,092 INFO [org.jboss.as.process.Host Controller.status] (main) WFLYPC0018: Starting process 'Host Controller'
> [Host Controller] 10:31:40,397 INFO [org.jboss.modules] (main) JBoss Modules version 1.5.2.Final
> [Host Controller] 10:31:40,512 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> [Host Controller] 10:31:40,544 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: Infinispan Server 9.1.0-SNAPSHOT (WildFly Core 2.2.0.Final) starting
> [Host Controller] 10:31:40,926 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'permgen-size' in the resource at address '/host=master/jvm=default' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> [Host Controller] 10:31:40,927 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'max-permgen-size' in the resource at address '/host=master/jvm=default' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> [Host Controller] 10:31:40,950 INFO [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0003: Creating http management service using network interface (management) port (9990) securePort (-1)
> [Host Controller] 10:31:40,953 INFO [org.xnio] (MSC service thread 1-1) XNIO version 3.4.0.Final
> [Host Controller] 10:31:40,960 INFO [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.4.0.Final
> [Host Controller] 10:31:40,988 INFO [org.jboss.remoting] (MSC service thread 1-4) JBoss Remoting version 4.0.21.Final
> [Host Controller] 10:31:41,017 INFO [org.jboss.as.remoting] (MSC service thread 1-7) WFLYRMT0001: Listening on 127.0.0.1:9999
> [Host Controller] 10:31:41,377 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'default-stack' in the resource at address '/profile=clustered/subsystem=datagrid-jgroups' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> [Host Controller] 10:31:41,473 INFO [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0023: Starting server server-one
> [Host Controller] 10:31:41,474 WARN [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0011: Ignoring <permgen> for jvm 'SUN' type jvm: default
> 10:31:41,522 INFO [org.jboss.as.process.Server:server-one.status] (ProcessController-threads - 3) WFLYPC0018: Starting process 'Server:server-one'
> [Host Controller] 10:31:41,565 WARN [org.jboss.as.host.controller] (ProcessControllerConnection-thread - 2) WFLYHC0011: Ignoring <permgen> for jvm 'SUN' type jvm: default
> [Server:server-one] 10:31:41,824 INFO [org.jboss.modules] (main) JBoss Modules version 1.5.2.Final
> [Server:server-one] java.lang.NullPointerException
> [Server:server-one] at org.jboss.as.server.DomainServerMain.main(DomainServerMain.java:116)
> [Server:server-one] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [Server:server-one] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [Server:server-one] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [Server:server-one] at java.lang.reflect.Method.invoke(Method.java:498)
> [Server:server-one] at org.jboss.modules.Module.run(Module.java:330)
> [Server:server-one] at org.jboss.modules.Main.main(Main.java:505)
> [Server:server-one] 10:31:41,901 FATAL [org.jboss.as.server] (main) WFLYSRV0239: Aborting with exit code 1
> [Server:server-one]
> 10:31:41,917 INFO [org.jboss.as.process.Server:server-one.status] (reaper for Server:server-one) WFLYPC0011: Process 'Server:server-one' finished with an exit status of 1
> [Host Controller] 10:31:41,960 INFO [org.jboss.as.host.controller] (ProcessControllerConnection-thread - 2) WFLYHC0027: Unregistering server server-one
> [Host Controller] 10:31:41,961 INFO [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0023: Starting server server-two
> [Host Controller] 10:31:41,961 WARN [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0011: Ignoring <permgen> for jvm 'SUN' type jvm: default
> 10:31:42,045 INFO [org.jboss.as.process.Server:server-two.status] (ProcessController-threads - 3) WFLYPC0018: Starting process 'Server:server-two'
> [Host Controller] 10:31:42,088 WARN [org.jboss.as.host.controller] (ProcessControllerConnection-thread - 2) WFLYHC0011: Ignoring <permgen> for jvm 'SUN' type jvm: default
> [Server:server-two] 10:31:42,365 INFO [org.jboss.modules] (main) JBoss Modules version 1.5.2.Final
> [Server:server-two] java.lang.NullPointerException
> [Server:server-two] at org.jboss.as.server.DomainServerMain.main(DomainServerMain.java:116)
> [Server:server-two] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [Server:server-two] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [Server:server-two] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [Server:server-two] at java.lang.reflect.Method.invoke(Method.java:498)
> [Server:server-two] at org.jboss.modules.Module.run(Module.java:330)
> [Server:server-two] at org.jboss.modules.Main.main(Main.java:505)
> [Server:server-two] 10:31:42,444 FATAL [org.jboss.as.server] (main) WFLYSRV0239: Aborting with exit code 1
> [Server:server-two]
> 10:31:42,463 INFO [org.jboss.as.process.Server:server-two.status] (reaper for Server:server-two) WFLYPC0011: Process 'Server:server-two' finished with an exit status of 1
> [Host Controller] 10:31:42,505 INFO [org.jboss.as.host.controller] (ProcessControllerConnection-thread - 2) WFLYHC0027: Unregistering server server-two
> [Host Controller] 10:31:42,512 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
> [Host Controller] 10:31:42,513 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
> [Host Controller] 10:31:42,513 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: Infinispan Server 9.1.0-SNAPSHOT (WildFly Core 2.2.0.Final) (Host Controller) started in 2356ms - Started 53 of 55 services (17 services are lazy, passive or on-demand)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ISPN-7838) JBoss Modules NPE in Domain mode
by Ryan Emerson (JIRA)
Ryan Emerson created ISPN-7838:
----------------------------------
Summary: JBoss Modules NPE in Domain mode
Key: ISPN-7838
URL: https://issues.jboss.org/browse/ISPN-7838
Project: Infinispan
Issue Type: Bug
Components: Server, WildFly modules
Affects Versions: 9.1.0.Alpha1
Reporter: Ryan Emerson
When starting the server in domain mode, the bellow errors are present on the server nodes. This seems to have been introduced by this [commit|https://github.com/infinispan/infinispan/commit/8401553ea9a64d5445...] for ISPN-7652.
{code:java}
10:31:40,010 INFO [org.jboss.modules] (main) JBoss Modules version 1.5.2.Final
10:31:40,092 INFO [org.jboss.as.process.Host Controller.status] (main) WFLYPC0018: Starting process 'Host Controller'
[Host Controller] 10:31:40,397 INFO [org.jboss.modules] (main) JBoss Modules version 1.5.2.Final
[Host Controller] 10:31:40,512 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
[Host Controller] 10:31:40,544 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: Infinispan Server 9.1.0-SNAPSHOT (WildFly Core 2.2.0.Final) starting
[Host Controller] 10:31:40,926 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'permgen-size' in the resource at address '/host=master/jvm=default' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
[Host Controller] 10:31:40,927 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'max-permgen-size' in the resource at address '/host=master/jvm=default' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
[Host Controller] 10:31:40,950 INFO [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0003: Creating http management service using network interface (management) port (9990) securePort (-1)
[Host Controller] 10:31:40,953 INFO [org.xnio] (MSC service thread 1-1) XNIO version 3.4.0.Final
[Host Controller] 10:31:40,960 INFO [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.4.0.Final
[Host Controller] 10:31:40,988 INFO [org.jboss.remoting] (MSC service thread 1-4) JBoss Remoting version 4.0.21.Final
[Host Controller] 10:31:41,017 INFO [org.jboss.as.remoting] (MSC service thread 1-7) WFLYRMT0001: Listening on 127.0.0.1:9999
[Host Controller] 10:31:41,377 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute 'default-stack' in the resource at address '/profile=clustered/subsystem=datagrid-jgroups' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
[Host Controller] 10:31:41,473 INFO [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0023: Starting server server-one
[Host Controller] 10:31:41,474 WARN [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0011: Ignoring <permgen> for jvm 'SUN' type jvm: default
10:31:41,522 INFO [org.jboss.as.process.Server:server-one.status] (ProcessController-threads - 3) WFLYPC0018: Starting process 'Server:server-one'
[Host Controller] 10:31:41,565 WARN [org.jboss.as.host.controller] (ProcessControllerConnection-thread - 2) WFLYHC0011: Ignoring <permgen> for jvm 'SUN' type jvm: default
[Server:server-one] 10:31:41,824 INFO [org.jboss.modules] (main) JBoss Modules version 1.5.2.Final
[Server:server-one] java.lang.NullPointerException
[Server:server-one] at org.jboss.as.server.DomainServerMain.main(DomainServerMain.java:116)
[Server:server-one] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[Server:server-one] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[Server:server-one] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[Server:server-one] at java.lang.reflect.Method.invoke(Method.java:498)
[Server:server-one] at org.jboss.modules.Module.run(Module.java:330)
[Server:server-one] at org.jboss.modules.Main.main(Main.java:505)
[Server:server-one] 10:31:41,901 FATAL [org.jboss.as.server] (main) WFLYSRV0239: Aborting with exit code 1
[Server:server-one]
10:31:41,917 INFO [org.jboss.as.process.Server:server-one.status] (reaper for Server:server-one) WFLYPC0011: Process 'Server:server-one' finished with an exit status of 1
[Host Controller] 10:31:41,960 INFO [org.jboss.as.host.controller] (ProcessControllerConnection-thread - 2) WFLYHC0027: Unregistering server server-one
[Host Controller] 10:31:41,961 INFO [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0023: Starting server server-two
[Host Controller] 10:31:41,961 WARN [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0011: Ignoring <permgen> for jvm 'SUN' type jvm: default
10:31:42,045 INFO [org.jboss.as.process.Server:server-two.status] (ProcessController-threads - 3) WFLYPC0018: Starting process 'Server:server-two'
[Host Controller] 10:31:42,088 WARN [org.jboss.as.host.controller] (ProcessControllerConnection-thread - 2) WFLYHC0011: Ignoring <permgen> for jvm 'SUN' type jvm: default
[Server:server-two] 10:31:42,365 INFO [org.jboss.modules] (main) JBoss Modules version 1.5.2.Final
[Server:server-two] java.lang.NullPointerException
[Server:server-two] at org.jboss.as.server.DomainServerMain.main(DomainServerMain.java:116)
[Server:server-two] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[Server:server-two] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[Server:server-two] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[Server:server-two] at java.lang.reflect.Method.invoke(Method.java:498)
[Server:server-two] at org.jboss.modules.Module.run(Module.java:330)
[Server:server-two] at org.jboss.modules.Main.main(Main.java:505)
[Server:server-two] 10:31:42,444 FATAL [org.jboss.as.server] (main) WFLYSRV0239: Aborting with exit code 1
[Server:server-two]
10:31:42,463 INFO [org.jboss.as.process.Server:server-two.status] (reaper for Server:server-two) WFLYPC0011: Process 'Server:server-two' finished with an exit status of 1
[Host Controller] 10:31:42,505 INFO [org.jboss.as.host.controller] (ProcessControllerConnection-thread - 2) WFLYHC0027: Unregistering server server-two
[Host Controller] 10:31:42,512 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
[Host Controller] 10:31:42,513 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
[Host Controller] 10:31:42,513 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: Infinispan Server 9.1.0-SNAPSHOT (WildFly Core 2.2.0.Final) (Host Controller) started in 2356ms - Started 53 of 55 services (17 services are lazy, passive or on-demand)
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ISPN-3795) QueryInterceptor incorrectly relies on the return value of a RemoveCommand
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-3795?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes commented on ISPN-3795:
-----------------------------------------
[~rvansa] +1 IGNORE_RETURN_VALUE should not be honored if prevents the indexing to work.
> QueryInterceptor incorrectly relies on the return value of a RemoveCommand
> --------------------------------------------------------------------------
>
> Key: ISPN-3795
> URL: https://issues.jboss.org/browse/ISPN-3795
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 6.0.0.Final
> Reporter: Dan Berindei
> Assignee: Gustavo Fernandes
>
> QueryInterceptor uses the return value from RemoveCommand/ReplaceCommand to remove the value from the index.
> But both RemoveCommand and ReplaceCommand have a variant with an expected value parameter, and this variant return a boolean value instead of the removed/replaced value. In that case, the previous value won't be removed from the index.
> QueryInterceptor should probably use the previous value from the context entries to update the index instead.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months