[JBoss JIRA] (ISPN-8897) Indexes from different caches are mixed-up in server mode
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-8897?page=com.atlassian.jira.plugin.... ]
Adrian Nistor reassigned ISPN-8897:
-----------------------------------
Assignee: Adrian Nistor (was: Gustavo Fernandes)
> Indexes from different caches are mixed-up in server mode
> ---------------------------------------------------------
>
> Key: ISPN-8897
> URL: https://issues.jboss.org/browse/ISPN-8897
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Querying
> Affects Versions: 9.1.6.Final, 9.2.0.Final
> Reporter: Gustavo Fernandes
> Assignee: Adrian Nistor
> Fix For: 9.2.1.Final
>
>
> When configuring multiple caches as indexed in the server, they'll effectively use the same index at runtime since Infinispan internally uses a single entity {{ProtobufValueWrapper}} to store the values in the index.
> This can cause issues with two caches having the same key stepping in each other's toes. Example, when doing:
> {code:java}
> remoteCache1.put(1, entity1)
> remoteCache2.put(1, entity2)
> {code}
> The second call will replace the first indexed entry since the key is identical and the internal index named "org.infinispan.query.remote.impl.indexing.ProtobufValueWrapper" is shared.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-8897) Indexes from different caches are mixed-up in server mode
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-8897?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-8897:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/5805
> Indexes from different caches are mixed-up in server mode
> ---------------------------------------------------------
>
> Key: ISPN-8897
> URL: https://issues.jboss.org/browse/ISPN-8897
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Querying
> Affects Versions: 9.1.6.Final, 9.2.0.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 9.2.1.Final
>
>
> When configuring multiple caches as indexed in the server, they'll effectively use the same index at runtime since Infinispan internally uses a single entity {{ProtobufValueWrapper}} to store the values in the index.
> This can cause issues with two caches having the same key stepping in each other's toes. Example, when doing:
> {code:java}
> remoteCache1.put(1, entity1)
> remoteCache2.put(1, entity2)
> {code}
> The second call will replace the first indexed entry since the key is identical and the internal index named "org.infinispan.query.remote.impl.indexing.ProtobufValueWrapper" is shared.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-8897) Indexes from different caches are mixed-up in server mode
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-8897?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-8897:
--------------------------------
Fix Version/s: 9.2.1.Final
> Indexes from different caches are mixed-up in server mode
> ---------------------------------------------------------
>
> Key: ISPN-8897
> URL: https://issues.jboss.org/browse/ISPN-8897
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Querying
> Affects Versions: 9.1.6.Final, 9.2.0.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 9.2.1.Final
>
>
> When configuring multiple caches as indexed in the server, they'll effectively use the same index at runtime since Infinispan internally uses a single entity {{ProtobufValueWrapper}} to store the values in the index.
> This can cause issues with two caches having the same key stepping in each other's toes. Example, when doing:
> {code:java}
> remoteCache1.put(1, entity1)
> remoteCache2.put(1, entity2)
> {code}
> The second call will replace the first indexed entry since the key is identical and the internal index named "org.infinispan.query.remote.impl.indexing.ProtobufValueWrapper" is shared.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-8897) Indexes from different caches are mixed-up in server mode
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-8897?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-8897:
--------------------------------
Status: Open (was: New)
> Indexes from different caches are mixed-up in server mode
> ---------------------------------------------------------
>
> Key: ISPN-8897
> URL: https://issues.jboss.org/browse/ISPN-8897
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Querying
> Affects Versions: 9.1.6.Final, 9.2.0.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
>
> When configuring multiple caches as indexed in the server, they'll effectively use the same index at runtime since Infinispan internally uses a single entity {{ProtobufValueWrapper}} to store the values in the index.
> This can cause issues with two caches having the same key stepping in each other's toes. Example, when doing:
> {code:java}
> remoteCache1.put(1, entity1)
> remoteCache2.put(1, entity2)
> {code}
> The second call will replace the first indexed entry since the key is identical and the internal index named "org.infinispan.query.remote.impl.indexing.ProtobufValueWrapper" is shared.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years
[JBoss JIRA] (ISPN-8900) Sockets might be left open if server unreachable on creation
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-8900?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-8900:
-----------------------------------
Status: Open (was: New)
> Sockets might be left open if server unreachable on creation
> ------------------------------------------------------------
>
> Key: ISPN-8900
> URL: https://issues.jboss.org/browse/ISPN-8900
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 9.1.6.Final, 9.2.0.Final
> Reporter: Galder Zamarreño
> Fix For: 9.2.1.Final, 9.1.7.Final
>
>
> Seems to affect pre-netty client but not sure yet whether it affects netty version:
> In 9.1.x and before, TcpTransport.destroy/release not called if TcpTransport constructor fails to connect socket. This might be leaving the socket file descriptor open. If an exception, socket and socketChannel should be closed.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years