June 2018 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-7711) Improve server-side protostream marshaller registration

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-7711?page=com.atlassian.jira.plugin.... ] Adrian Nistor commented on ISPN-7711: ------------------------------------- The issue of server-side protobuf schema and marshaller deployment was recently resolved by Gustavo while working on ISPN-9181 ISPN-9184. The solution is covered in the user guide here : https://github.com/infinispan/infinispan/pull/6045/files#diff-5d6e8f3e7a6... The solution was even simpler than what I described in an earlier comment as it does no longer need a DeploymentUnitProcessor, just a simple jar deployed in the server, containing implementations of ProtostreamSerializationContextInitializer that use the ServiceLoader mechanism (see https://github.com/infinispan/infinispan/blob/14afdf555b826d78622a534e50f...). This simplification was possible due to ISPN-7714. Remote server tasks were not seen fit for this purpose because they can only execute after the cache is fully started, which is too late. We need these marshallers available earlier, somewhere between cache manager startup and before cache startup. These marshallers and the related proto schemas need to be deployed before the indexing system of the cache starts or else the newly started cache cannot process/index the data that it will immediately start to receive via state transfer from other cluster members. > Improve server-side protostream marshaller registration > ------------------------------------------------------- > > Key: ISPN-7711 > URL: https://issues.jboss.org/browse/ISPN-7711 > Project: Infinispan > Issue Type: Enhancement > Reporter: Galder Zamarreño > Assignee: Adrian Nistor > Fix For: 9.4.0.Final > > > A more user friendly way to register protostream marshallers remotely is needed when the protostream marshaller is used for compatibility mode (or transcoding) in the future. It's currently possible to do it with a remote server task but that's a bit hacky. > This server task shows how it can be done: > {code} > package delays.java.stream; > import org.infinispan.manager.EmbeddedCacheManager; > import org.infinispan.query.remote.ProtobufMetadataManager; > import org.infinispan.tasks.ServerTask; > import org.infinispan.tasks.TaskContext; > import org.infinispan.tasks.TaskExecutionMode; > import delays.java.stream.pojos.Station; > import delays.java.stream.pojos.Stop; > import delays.java.stream.pojos.Train; > public class AddProtobufTask implements ServerTask { > private TaskContext ctx; > @Override > public void setTaskContext(TaskContext ctx) { > this.ctx = ctx; > } > @Override > public String getName() { > return "add-protobuf"; > } > @Override > public Object call() throws Exception { > EmbeddedCacheManager cm = ctx.getCache().get().getCacheManager(); > ProtobufMetadataManager protobufMetadataManager = cm.getGlobalComponentRegistry().getComponent(ProtobufMetadataManager.class); > protobufMetadataManager.registerMarshaller(new Stop.Marshaller()); > protobufMetadataManager.registerMarshaller(new Station.Marshaller()); > protobufMetadataManager.registerMarshaller(new Train.Marshaller()); > return null; > } > @Override > public TaskExecutionMode getExecutionMode() { > // Registering marshallers should be done in all nodes > return TaskExecutionMode.ALL_NODES; > } > } > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9292) PessimisticTxAtomicLockingTest and OptimisticTxAtomicLockingTest not running

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-9292?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-9292: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.4.0.Alpha1 Resolution: Done > PessimisticTxAtomicLockingTest and OptimisticTxAtomicLockingTest not running > ---------------------------------------------------------------------------- > > Key: ISPN-9292 > URL: https://issues.jboss.org/browse/ISPN-9292 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 9.3.0.CR1 > Reporter: Radim Vansa > Assignee: Radim Vansa > Fix For: 9.4.0.Alpha1 > > > These tests don't have the *Test suffix and are not run (by default). That's why these got broken with the RpcManager overhaul. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9323) RemoteCache.getWithMetadata returns expired metadata when server is transactional cache

by Marek Posolda (JIRA)

[ https://issues.jboss.org/browse/ISPN-9323?page=com.atlassian.jira.plugin.... ] Marek Posolda updated ISPN-9323: -------------------------------- Attachment: (was: RemoteCacheExpirationTest.java) > RemoteCache.getWithMetadata returns expired metadata when server is transactional cache > --------------------------------------------------------------------------------------- > > Key: ISPN-9323 > URL: https://issues.jboss.org/browse/ISPN-9323 > Project: Infinispan > Issue Type: Bug > Components: Hot Rod, Server > Affects Versions: 9.3.0.CR1, 9.2.4.Final > Reporter: Marek Posolda > Attachments: RemoteCacheExpirationTest.java > > > I have transactional cache defined on server side (infinispan-server). I have HotRod client application (RemoteCache), which is connected to server above and which calls this: > {code} > remoteCache.put("key", "value", 1000, TimeUnit.SECONDS, 100, TimeUnit.SECONDS); > MetadataValue loaded = remoteCache.getWithMetadata("key"); > System.out.println("created: " + loaded.getCreated() + ", lastUsed: " + loaded.getLastUsed()); > {code} > The output is: > {code} > created: 0, lastUsed: 0 > {code} > This is not correct and causes some issues as entries are treated as expired. Especially when used together with remote-store, which is not able to load such entries, as PersistenceUtil#loadAndCheckExpiration method always treat the item loaded from RemoteCache as expired. See the attached application for more details. > STEPS TO REPRODUCE: > 1) Use infinispan-server-9.2.4.Final on server side and HotRod client (RemoteCache) version 9.2.4.Final on client side (maven dependency org.infinispan:infinispan-client-hotrod:9.2.4.Final for client app) > 2) Unzip server 9.2.4.Final to some directory > 3) Change ISPN_SERVER_HOME/standalone/configuration/clustered.xml and just add this transactional cache to the cache-container (NOTE: configuration "transactional" is already defined in the clustered.xml file): > {code} > <distributed-cache name="trans" configuration="transactional" /> > {code} > 4) Run server with: > {code} > ./standalone.sh -c clustered.xml > {code} > 5) Run the client application from attachement. You can see the output as described above and also that entry is considered as expired (Example app uses same algorithm like RemoteStore together with PersistenceUtil.loadAndCheckExpired ). Original sources here: https://github.com/mposolda/misc/blob/master/ispn-client-listener/src/mai... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9323) RemoteCache.getWithMetadata returns expired metadata when server is transactional cache

by Marek Posolda (JIRA)

[ https://issues.jboss.org/browse/ISPN-9323?page=com.atlassian.jira.plugin.... ] Marek Posolda updated ISPN-9323: -------------------------------- Attachment: RemoteCacheExpirationTest.java > RemoteCache.getWithMetadata returns expired metadata when server is transactional cache > --------------------------------------------------------------------------------------- > > Key: ISPN-9323 > URL: https://issues.jboss.org/browse/ISPN-9323 > Project: Infinispan > Issue Type: Bug > Components: Hot Rod, Server > Affects Versions: 9.3.0.CR1, 9.2.4.Final > Reporter: Marek Posolda > Attachments: RemoteCacheExpirationTest.java > > > I have transactional cache defined on server side (infinispan-server). I have HotRod client application (RemoteCache), which is connected to server above and which calls this: > {code} > remoteCache.put("key", "value", 1000, TimeUnit.SECONDS, 100, TimeUnit.SECONDS); > MetadataValue loaded = remoteCache.getWithMetadata("key"); > System.out.println("created: " + loaded.getCreated() + ", lastUsed: " + loaded.getLastUsed()); > {code} > The output is: > {code} > created: 0, lastUsed: 0 > {code} > This is not correct and causes some issues as entries are treated as expired. Especially when used together with remote-store, which is not able to load such entries, as PersistenceUtil#loadAndCheckExpiration method always treat the item loaded from RemoteCache as expired. See the attached application for more details. > STEPS TO REPRODUCE: > 1) Use infinispan-server-9.2.4.Final on server side and HotRod client (RemoteCache) version 9.2.4.Final on client side (maven dependency org.infinispan:infinispan-client-hotrod:9.2.4.Final for client app) > 2) Unzip server 9.2.4.Final to some directory > 3) Change ISPN_SERVER_HOME/standalone/configuration/clustered.xml and just add this transactional cache to the cache-container (NOTE: configuration "transactional" is already defined in the clustered.xml file): > {code} > <distributed-cache name="trans" configuration="transactional" /> > {code} > 4) Run server with: > {code} > ./standalone.sh -c clustered.xml > {code} > 5) Run the client application from attachement. You can see the output as described above and also that entry is considered as expired (Example app uses same algorithm like RemoteStore together with PersistenceUtil.loadAndCheckExpired ). Original sources here: https://github.com/mposolda/misc/blob/master/ispn-client-listener/src/mai... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5083) Hot Rod decoder should use async Cache operations

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-5083?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-5083: ----------------------------------- [~galder.zamarreno] Shouldn't we close this? > Hot Rod decoder should use async Cache operations > ------------------------------------------------- > > Key: ISPN-5083 > URL: https://issues.jboss.org/browse/ISPN-5083 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Protocols > Reporter: Galder Zamarreño > Fix For: 9.4.0.Final > > > Hot Rod decoder is currently tying up Netty threads as a result of calling up to Infinispan sync operations. Instead, Hot Rod decoder should call up async operations, convert the Notifying Futures to Scala Futures, and write up the reply when it's received. This should increase performance specially under heavy load. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9155) Clear should not emit listener notifications

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-9155?page=com.atlassian.jira.plugin.... ] Radim Vansa edited comment on ISPN-9155 at 6/25/18 10:44 AM: ------------------------------------------------------------- [~galder.zamarreno] Hmm, the timestamp does not seem like having too many beers before typing that :) Anyway, I meant that I wouldn't change the semantics of *embedded* {{clear()}} as this could break integrations or complex use cases. I wouldn't mind too much in case of *remote* as I don't expect anyone to really invoke that in production. We can handle the indexing separately, wiping out the indices without relying on the listeners. That approach would leave us with not invoked remote listeners and stale entries in near cache. was (Author: rvansa): [~galder.zamarreno] Hmm, the timestamp does not seem like having too many beers before typing that :) Anyway, I meant that I wouldn't change the semantics of *embedded* {{clear()}} as this could break integrations or complex use cases. I wouldn't mind too much in case of *remote* as I don't expect anyone to really invoke that in production. We can handle the indexing separately, wiping out the indices without relying on the listeners. > Clear should not emit listener notifications > -------------------------------------------- > > Key: ISPN-9155 > URL: https://issues.jboss.org/browse/ISPN-9155 > Project: Infinispan > Issue Type: Enhancement > Components: Listeners, Remote Protocols > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Labels: redhat-summit-18 > Fix For: 9.3.0.CR1, 9.4.0.Final > > > JCache does not emit notifications on clear(). We shouldn't either. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9155) Clear should not emit listener notifications

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-9155?page=com.atlassian.jira.plugin.... ] Radim Vansa edited comment on ISPN-9155 at 6/25/18 10:43 AM: ------------------------------------------------------------- [~galder.zamarreno] Hmm, the timestamp does not seem like having too many beers before typing that :) Anyway, I meant that I wouldn't change the semantics of *embedded* {{clear()}} as this could break integrations or complex use cases. I wouldn't mind too much in case of *remote* as I don't expect anyone to really invoke that in production. We can handle the indexing separately, wiping out the indices without relying on the listeners. was (Author: rvansa): [~galder.zamarreno] Hmm, the timestamp does not seem like having too many beers before typing that :) Anyway, I meant that I wouldn't change the semantics of *embedded* {{clear()}} as this could break integrations or complex use cases. I wouldn't mind too much in case of *remote* as I don't expect anyone (but indexing) to really invoke that in production. We can handle the indexing separately, wiping out the indices without relying on the listeners. > Clear should not emit listener notifications > -------------------------------------------- > > Key: ISPN-9155 > URL: https://issues.jboss.org/browse/ISPN-9155 > Project: Infinispan > Issue Type: Enhancement > Components: Listeners, Remote Protocols > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Labels: redhat-summit-18 > Fix For: 9.3.0.CR1, 9.4.0.Final > > > JCache does not emit notifications on clear(). We shouldn't either. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9155) Clear should not emit listener notifications

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-9155?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-9155: ----------------------------------- [~galder.zamarreno] Hmm, the timestamp does not seem like having too many beers before typing that :) Anyway, I meant that I wouldn't change the semantics of *embedded* {{clear()}} as this could break integrations or complex use cases. I wouldn't mind too much in case of *remote* as I don't expect anyone (but indexing) to really invoke that in production. We can handle the indexing separately, wiping out the indices without relying on the listeners. > Clear should not emit listener notifications > -------------------------------------------- > > Key: ISPN-9155 > URL: https://issues.jboss.org/browse/ISPN-9155 > Project: Infinispan > Issue Type: Enhancement > Components: Listeners, Remote Protocols > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Labels: redhat-summit-18 > Fix For: 9.3.0.CR1, 9.4.0.Final > > > JCache does not emit notifications on clear(). We shouldn't either. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9321) Maven parallel builds are broken

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-9321?page=com.atlassian.jira.plugin.... ] Ryan Emerson resolved ISPN-9321. -------------------------------- Fix Version/s: 9.4.0.Alpha1 Resolution: Done > Maven parallel builds are broken > -------------------------------- > > Key: ISPN-9321 > URL: https://issues.jboss.org/browse/ISPN-9321 > Project: Infinispan > Issue Type: Bug > Components: Build > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 9.4.0.Alpha1 > > > {{mvn clean install -DskipTests=true -s maven-settings.xml -T3C}} > causes errors: > {noformat} > [ERROR] Failed to execute goal org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.2.10.Final:build > (server-provisioning-node2) on project infinispan-as-lucene-integration: Execution server-provisioning-node2 of goal > org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.2.10.Final:build failed: java.lang.RuntimeException: java.io.FileNotFoundException: /home/gfernandes/github/infinispan/query/target/classes (Is a directory) -> [Help 1] > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-60) Make WrappedMessage.readMessage/writeMessage/Marshaller package local

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/IPROTO-60?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated IPROTO-60: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/protostream/pull/38 > Make WrappedMessage.readMessage/writeMessage/Marshaller package local > --------------------------------------------------------------------- > > Key: IPROTO-60 > URL: https://issues.jboss.org/browse/IPROTO-60 > Project: Infinispan ProtoStream > Issue Type: Bug > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 4.3.0.Alpha1, 4.3.0.Final > > > These were mistakenly left public but were never intended to be used from outside. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2018