May 2018 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-9220) Client listeners are sometimes re-registered twice after infinispan-server restart

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-9220?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-9220: ----------------------------------- Labels: redhat-summit-18 (was: ) > Client listeners are sometimes re-registered twice after infinispan-server restart > ---------------------------------------------------------------------------------- > > Key: ISPN-9220 > URL: https://issues.jboss.org/browse/ISPN-9220 > Project: Infinispan > Issue Type: Bug > Components: Hot Rod > Affects Versions: 9.2.1.Final > Reporter: Marek Posolda > Labels: redhat-summit-18 > > During test of summit, we saw some issue with client listeners. Setup was this: > - Every site had one hotrod client (RHSSO), which used infinispan of version 8.2.8.Final and one infinispan-server, which I think was version 9.2.1.Final > - Client (RH-SSO) had some client listener registered against remoteCache > - After restart of infinispan-server, the RH-SSO was able to re-connect to it and CRUD the items to the remoteCache. But previously registered clientListeners were lost. > Note that setup demo used just 1 infinispan-server on every site, so there were not any topology changes (no possibility of re-balance client listener to other node). > I've tried to do simple reproducer for the scenario above and verified that with client 8.2.8.Final and server 9.2.1.Final, the client listener is not automatically re-registered after restart. > BUT after upgrade client to 9.2.1.Final, re-registration worked fine and client listener was re-registered automatically. This is important as from long term perspective, we are upgrading to infinispan 9 on RH-SSO side. But I had the opposite issue, that sometimes the client listener is registered twice. See steps to reproduce for the details. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9222) Custom clientListener filters without a need to deploy java code to Infinispan server

by Marek Posolda (JIRA)

[ https://issues.jboss.org/browse/ISPN-9222?page=com.atlassian.jira.plugin.... ] Marek Posolda commented on ISPN-9222: ------------------------------------- [~anistor] Cool! Thanks a lot for pointing that. Will need to doublecheck the docs. Maybe it's in the docs already, but I just missed that. TBH it may help with exposing the docs if you make the "Developer guide" visible in community as well? But I guess it's on purpose that it's available just for the JDG product? > Custom clientListener filters without a need to deploy java code to Infinispan server > ------------------------------------------------------------------------------------- > > Key: ISPN-9222 > URL: https://issues.jboss.org/browse/ISPN-9222 > Project: Infinispan > Issue Type: Task > Components: Hot Rod > Affects Versions: 9.2.1.Final > Reporter: Marek Posolda > Assignee: Adrian Nistor > > Currently JDG has a way to register client listeners for the remote HotRod events. There are also ways to filter the events, so that client listener doesn't receive the filtered events, which it's not interested in. But it looks that filtering currently requires custom code with CacheEventFilterFactory to be available on JDG server side as described in https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.2... . > I was wondering if it's possible to have custom filter, which is able to somehow filter fields of custom objects without a need to deploy custom code to the Infinispan/JDG server? Both the object and CacheEventFilterFactory to not be required on JDG side. AFAIK the protobuf schema could be used to query custom objects on JDG server side without having the code of the objects available on the JDG side? So iwas thinking about something similar. > More details: Let's assume that on HotRod client side, I have entity like this: > {code} > public class UserEntity { > private String username; > private String email; > private String country; > } > {code} > I will be able to create client listener like this (I don't need to deploy "protobuf-factory". It will be available on JDG out of the box): > {code} > @org.infinispan.client.hotrod.annotation.ClientListener(filterFactoryName = "protobuf-factory") > public class CustomLogListener { > ... > } > {code} > Then I will be able to use the examples like this to register client listener on client side (just an example how can the filtering "psudo-language" look like): > Interested just for users from Czech republic: > {code} > remoteCache.addClientListener(listener, new String[] { "country.equals('cs')" }, null); > {code} > Interested just for users from Czech republic with emails from "@redhat.com": > {code} > remoteCache.addClientListener(listener, new String[] { "country.equals('cs') && email.endsWith('@redhat.com')" }, null); > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9222) Custom clientListener filters without a need to deploy java code to Infinispan server

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-9222?page=com.atlassian.jira.plugin.... ] Adrian Nistor commented on ISPN-9222: ------------------------------------- Since the functionality already exists, we might want to think about better ways to expose it so it is more visible. Improve the documentation too... > Custom clientListener filters without a need to deploy java code to Infinispan server > ------------------------------------------------------------------------------------- > > Key: ISPN-9222 > URL: https://issues.jboss.org/browse/ISPN-9222 > Project: Infinispan > Issue Type: Task > Components: Hot Rod > Affects Versions: 9.2.1.Final > Reporter: Marek Posolda > Assignee: Adrian Nistor > > Currently JDG has a way to register client listeners for the remote HotRod events. There are also ways to filter the events, so that client listener doesn't receive the filtered events, which it's not interested in. But it looks that filtering currently requires custom code with CacheEventFilterFactory to be available on JDG server side as described in https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.2... . > I was wondering if it's possible to have custom filter, which is able to somehow filter fields of custom objects without a need to deploy custom code to the Infinispan/JDG server? Both the object and CacheEventFilterFactory to not be required on JDG side. AFAIK the protobuf schema could be used to query custom objects on JDG server side without having the code of the objects available on the JDG side? So iwas thinking about something similar. > More details: Let's assume that on HotRod client side, I have entity like this: > {code} > public class UserEntity { > private String username; > private String email; > private String country; > } > {code} > I will be able to create client listener like this (I don't need to deploy "protobuf-factory". It will be available on JDG out of the box): > {code} > @org.infinispan.client.hotrod.annotation.ClientListener(filterFactoryName = "protobuf-factory") > public class CustomLogListener { > ... > } > {code} > Then I will be able to use the examples like this to register client listener on client side (just an example how can the filtering "psudo-language" look like): > Interested just for users from Czech republic: > {code} > remoteCache.addClientListener(listener, new String[] { "country.equals('cs')" }, null); > {code} > Interested just for users from Czech republic with emails from "@redhat.com": > {code} > remoteCache.addClientListener(listener, new String[] { "country.equals('cs') && email.endsWith('@redhat.com')" }, null); > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9222) Custom clientListener filters without a need to deploy java code to Infinispan server

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-9222?page=com.atlassian.jira.plugin.... ] Adrian Nistor edited comment on ISPN-9222 at 5/30/18 4:24 AM: -------------------------------------------------------------- [~mposolda] Hi, you are getting very close to the treasure :) This is already doable since ispn 7 or 8, don't remember exactly. Please have a look at RemoteListenerWithDslFilterTest which uses hot rod with a client listener + a query to filter the events. You'll have to use protobuf encoding of course. Registering the listener is done via ClientEvents.addClientQueryListener which takes an org.infinispan.query.dsl.Query parameter. This query can either be built with the QueryBuilder using the fluent DSL or can be obtained using QueryFactory.create(..) with an Ickle query string. ATM the method is in ClientEvents but could be moved to the remote cache interface in the future as you suggested. was (Author: anistor): [~mposolda] Hi, you are getting very close to the treasure :) This is already doable since ispn 7 or 8, don;t remember exactly. Please have a look at RemoteListenerWithDslFilterTest which uses hot rod with a client listener + a query to filter the events. You'll have to use protobuf encoding of course. Registering the listener is done via ClientEvents.addClientQueryListener which takes a org.infinispan.query.dsl.Query parameter. This query can either be built with the QueryBuilder using the fluent DSL or can obtained using QueryFactory.create(..) with an Ickle query string. ATM the method is in ClientEvents but could be moved to the remote cache interface in the future as you suggested. > Custom clientListener filters without a need to deploy java code to Infinispan server > ------------------------------------------------------------------------------------- > > Key: ISPN-9222 > URL: https://issues.jboss.org/browse/ISPN-9222 > Project: Infinispan > Issue Type: Task > Components: Hot Rod > Affects Versions: 9.2.1.Final > Reporter: Marek Posolda > > Currently JDG has a way to register client listeners for the remote HotRod events. There are also ways to filter the events, so that client listener doesn't receive the filtered events, which it's not interested in. But it looks that filtering currently requires custom code with CacheEventFilterFactory to be available on JDG server side as described in https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.2... . > I was wondering if it's possible to have custom filter, which is able to somehow filter fields of custom objects without a need to deploy custom code to the Infinispan/JDG server? Both the object and CacheEventFilterFactory to not be required on JDG side. AFAIK the protobuf schema could be used to query custom objects on JDG server side without having the code of the objects available on the JDG side? So iwas thinking about something similar. > More details: Let's assume that on HotRod client side, I have entity like this: > {code} > public class UserEntity { > private String username; > private String email; > private String country; > } > {code} > I will be able to create client listener like this (I don't need to deploy "protobuf-factory". It will be available on JDG out of the box): > {code} > @org.infinispan.client.hotrod.annotation.ClientListener(filterFactoryName = "protobuf-factory") > public class CustomLogListener { > ... > } > {code} > Then I will be able to use the examples like this to register client listener on client side (just an example how can the filtering "psudo-language" look like): > Interested just for users from Czech republic: > {code} > remoteCache.addClientListener(listener, new String[] { "country.equals('cs')" }, null); > {code} > Interested just for users from Czech republic with emails from "@redhat.com": > {code} > remoteCache.addClientListener(listener, new String[] { "country.equals('cs') && email.endsWith('@redhat.com')" }, null); > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9222) Custom clientListener filters without a need to deploy java code to Infinispan server

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-9222?page=com.atlassian.jira.plugin.... ] Adrian Nistor reassigned ISPN-9222: ----------------------------------- Assignee: Adrian Nistor > Custom clientListener filters without a need to deploy java code to Infinispan server > ------------------------------------------------------------------------------------- > > Key: ISPN-9222 > URL: https://issues.jboss.org/browse/ISPN-9222 > Project: Infinispan > Issue Type: Task > Components: Hot Rod > Affects Versions: 9.2.1.Final > Reporter: Marek Posolda > Assignee: Adrian Nistor > > Currently JDG has a way to register client listeners for the remote HotRod events. There are also ways to filter the events, so that client listener doesn't receive the filtered events, which it's not interested in. But it looks that filtering currently requires custom code with CacheEventFilterFactory to be available on JDG server side as described in https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.2... . > I was wondering if it's possible to have custom filter, which is able to somehow filter fields of custom objects without a need to deploy custom code to the Infinispan/JDG server? Both the object and CacheEventFilterFactory to not be required on JDG side. AFAIK the protobuf schema could be used to query custom objects on JDG server side without having the code of the objects available on the JDG side? So iwas thinking about something similar. > More details: Let's assume that on HotRod client side, I have entity like this: > {code} > public class UserEntity { > private String username; > private String email; > private String country; > } > {code} > I will be able to create client listener like this (I don't need to deploy "protobuf-factory". It will be available on JDG out of the box): > {code} > @org.infinispan.client.hotrod.annotation.ClientListener(filterFactoryName = "protobuf-factory") > public class CustomLogListener { > ... > } > {code} > Then I will be able to use the examples like this to register client listener on client side (just an example how can the filtering "psudo-language" look like): > Interested just for users from Czech republic: > {code} > remoteCache.addClientListener(listener, new String[] { "country.equals('cs')" }, null); > {code} > Interested just for users from Czech republic with emails from "@redhat.com": > {code} > remoteCache.addClientListener(listener, new String[] { "country.equals('cs') && email.endsWith('@redhat.com')" }, null); > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9222) Custom clientListener filters without a need to deploy java code to Infinispan server

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-9222?page=com.atlassian.jira.plugin.... ] Adrian Nistor commented on ISPN-9222: ------------------------------------- [~mposolda] Hi, you are getting very close to the treasure :) This is already doable since ispn 7 or 8, don;t remember exactly. Please have a look at RemoteListenerWithDslFilterTest which uses hot rod with a client listener + a query to filter the events. You'll have to use protobuf encoding of course. Registering the listener is done via ClientEvents.addClientQueryListener which takes a org.infinispan.query.dsl.Query parameter. This query can either be built with the QueryBuilder using the fluent DSL or can obtained using QueryFactory.create(..) with an Ickle query string. ATM the method is in ClientEvents but could be moved to the remote cache interface in the future as you suggested. > Custom clientListener filters without a need to deploy java code to Infinispan server > ------------------------------------------------------------------------------------- > > Key: ISPN-9222 > URL: https://issues.jboss.org/browse/ISPN-9222 > Project: Infinispan > Issue Type: Task > Components: Hot Rod > Affects Versions: 9.2.1.Final > Reporter: Marek Posolda > > Currently JDG has a way to register client listeners for the remote HotRod events. There are also ways to filter the events, so that client listener doesn't receive the filtered events, which it's not interested in. But it looks that filtering currently requires custom code with CacheEventFilterFactory to be available on JDG server side as described in https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.2... . > I was wondering if it's possible to have custom filter, which is able to somehow filter fields of custom objects without a need to deploy custom code to the Infinispan/JDG server? Both the object and CacheEventFilterFactory to not be required on JDG side. AFAIK the protobuf schema could be used to query custom objects on JDG server side without having the code of the objects available on the JDG side? So iwas thinking about something similar. > More details: Let's assume that on HotRod client side, I have entity like this: > {code} > public class UserEntity { > private String username; > private String email; > private String country; > } > {code} > I will be able to create client listener like this (I don't need to deploy "protobuf-factory". It will be available on JDG out of the box): > {code} > @org.infinispan.client.hotrod.annotation.ClientListener(filterFactoryName = "protobuf-factory") > public class CustomLogListener { > ... > } > {code} > Then I will be able to use the examples like this to register client listener on client side (just an example how can the filtering "psudo-language" look like): > Interested just for users from Czech republic: > {code} > remoteCache.addClientListener(listener, new String[] { "country.equals('cs')" }, null); > {code} > Interested just for users from Czech republic with emails from "@redhat.com": > {code} > remoteCache.addClientListener(listener, new String[] { "country.equals('cs') && email.endsWith('@redhat.com')" }, null); > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9222) Custom clientListener filters without a need to deploy java code to Infinispan server

by Marek Posolda (JIRA)

Marek Posolda created ISPN-9222: ----------------------------------- Summary: Custom clientListener filters without a need to deploy java code to Infinispan server Key: ISPN-9222 URL: https://issues.jboss.org/browse/ISPN-9222 Project: Infinispan Issue Type: Task Components: Hot Rod Affects Versions: 9.2.1.Final Reporter: Marek Posolda Currently JDG has a way to register client listeners for the remote HotRod events. There are also ways to filter the events, so that client listener doesn't receive the filtered events, which it's not interested in. But it looks that filtering currently requires custom code with CacheEventFilterFactory to be available on JDG server side as described in https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.2... . I was wondering if it's possible to have custom filter, which is able to somehow filter fields of custom objects without a need to deploy custom code to the Infinispan/JDG server? Both the object and CacheEventFilterFactory to not be required on JDG side. AFAIK the protobuf schema could be used to query custom objects on JDG server side without having the code of the objects available on the JDG side? So iwas thinking about something similar. More details: Let's assume that on HotRod client side, I have entity like this: {code} public class UserEntity { private String username; private String email; private String country; } {code} I will be able to create client listener like this (I don't need to deploy "protobuf-factory". It will be available on JDG out of the box): {code} @org.infinispan.client.hotrod.annotation.ClientListener(filterFactoryName = "protobuf-factory") public class CustomLogListener { ... } {code} Then I will be able to use the examples like this to register client listener on client side (just an example how can the filtering "psudo-language" look like): Interested just for users from Czech republic: {code} remoteCache.addClientListener(listener, new String[] { "country.equals('cs')" }, null); {code} Interested just for users from Czech republic with emails from "@redhat.com": {code} remoteCache.addClientListener(listener, new String[] { "country.equals('cs') && email.endsWith('@redhat.com')" }, null); {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9221) State transfer in x-site scenarios

by Marek Posolda (JIRA)

Marek Posolda created ISPN-9221: ----------------------------------- Summary: State transfer in x-site scenarios Key: ISPN-9221 URL: https://issues.jboss.org/browse/ISPN-9221 Project: Infinispan Issue Type: Task Components: Cross-Site Replication Affects Versions: 9.2.1.Final Reporter: Marek Posolda Currently if state stransfer is required in the x-site scenarios, it needs to be triggered manually through CLI or JMX. Will be nice if there is a possibility to somehow automatically setup state transfer OOTB, which will be triggered when new site joins the cloud OR when site joins the cloud after previously temporarily disconnected (split-brain). - It could be good to setup this unidirectionally or bi-directionally. In case of bi-directional, every site may receive the entities, which were created in the meantime on the other site. For already existing entities, there could be some strategies like IGNORE_EXISTING, OVERRIDE_EXISTING etc. So in case that some entity exist on both sites, it may be possible to choose one site to have bigger priority and "win" . So for example in case that site1 has bigger priority than site2 and strategy is OVERRIDE_EXISTING, then entity "123" will be always overriden on site2 with the value from site1. - Things might be even more tricky to properly support removals or updates during split-brain. That could require to track the removed entities for some time. For example, the scenario like: -- The entity "123" exists on both sites -- In time 10:00 there is split-brain -- In time 10:05 the entity "123" was removed on site2 -- In time 10:06 the entity "456" was created on site1 -- In time 10:10 the split-brain is "fixed" and sites are re-connected. At this moment, both entities with keys "123" and "456" are available just on site1, but not on site2. ATM I want the new entity "456" to be created on site2, but I don't want the entity "123" to be re-created on site2 based on the value from site1. Instead I want "123" to be removed on site1. I don't know how hard would be to properly support the example above or if it's even doable considering various corner cases. Just added it for completeness :) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9220) Client listeners are sometimes re-registered twice after infinispan-server restart

by Marek Posolda (JIRA)

[ https://issues.jboss.org/browse/ISPN-9220?page=com.atlassian.jira.plugin.... ] Marek Posolda updated ISPN-9220: -------------------------------- Steps to Reproduce: I was not able to reliably reproduce why the client listener is re-registered twice without debugger. I've needed to use the debugger and this helps to reliable reproduce it in my environment. 1) Unzip infinispan-server 9.2.1.Final and run with: {code} cd infinispan-server-9.2.1.Final/bin/ ./standalone.sh -c clustered.xml {code} 2) Run this Java application from IDE in debug mode https://github.com/mposolda/misc/blob/master/ispn-client-listener/src/mai... . Make sure that infinispan version (Version of infinispan on client side) is 9.2.1.Final (property "ispn.version" in this file: https://github.com/mposolda/misc/blob/master/ispn-client-listener/pom.xml After application is executed, you can see that items are added and client listener is triggered as expected: {code} May 30, 2018 9:53:12 AM org.mposolda.ClientListenerFailoverTest main INFO: RemoteCache created May 30, 2018 9:53:13 AM org.mposolda.ClientListenerFailoverTest main INFO: Adding key: key-0 May 30, 2018 9:53:13 AM org.mposolda.ClientListenerFailoverTest$HotRodListener created INFO: Listener: created: key-0 May 30, 2018 9:53:14 AM org.mposolda.ClientListenerFailoverTest main INFO: Adding key: key-1 May 30, 2018 9:53:14 AM org.mposolda.ClientListenerFailoverTest$HotRodListener created INFO: Listener: created: key-1 May 30, 2018 9:53:15 AM org.mposolda.ClientListenerFailoverTest main INFO: Adding key: key-2 May 30, 2018 9:53:15 AM org.mposolda.ClientListenerFailoverTest$HotRodListener created INFO: Listener: created: key-2 May 30, 2018 9:53:16 AM org.mposolda.ClientListenerFailoverTest main INFO: Adding key: key-3 May 30, 2018 9:53:16 AM org.mposolda.ClientListenerFailoverTest$HotRodListener created INFO: Listener: created: key-3 May 30, 2018 9:53:17 AM org.mposolda.ClientListenerFailoverTest main INFO: Adding key: key-4 May 30, 2018 9:53:17 AM org.mposolda.ClientListenerFailoverTest$HotRodListener created INFO: Listener: created: key-4 May 30, 2018 9:53:18 AM org.mposolda.ClientListenerFailoverTest main INFO: Adding key: key-5 May 30, 2018 9:53:18 AM org.mposolda.ClientListenerFailoverTest$HotRodListener created INFO: Listener: created: key-5 .... {code} 3) Add breakpoint to class org.infinispan.client.hotrod.impl.operations.AddClientListenerOperation to the beginning of method "execute(Channel channel)" 4) Restart infinispan-server 5) After server is restarted, the method AddClientListenerOperation.execute is invoked. Wait with breakpoint at least 10 seconds to reproduce the issue. 6) Continue with breakpoint and see that method is executed another time. Continue with breakpoint again. 7) Now I can see that clientListener is executed twice for each added item, which is NOT ok. {code} .... INFO: Adding key: key-189 May 30, 2018 9:56:23 AM org.mposolda.ClientListenerFailoverTest$HotRodListener created INFO: Listener: created: key-189 May 30, 2018 9:56:23 AM org.mposolda.ClientListenerFailoverTest$HotRodListener created INFO: Listener: created: key-189 May 30, 2018 9:56:24 AM org.mposolda.ClientListenerFailoverTest main INFO: Adding key: key-190 May 30, 2018 9:56:24 AM org.mposolda.ClientListenerFailoverTest$HotRodListener created INFO: Listener: created: key-190 May 30, 2018 9:56:24 AM org.mposolda.ClientListenerFailoverTest$HotRodListener created INFO: Listener: created: key-190 May 30, 2018 9:56:25 AM org.mposolda.ClientListenerFailoverTest main INFO: Adding key: key-191 May 30, 2018 9:56:25 AM org.mposolda.ClientListenerFailoverTest$HotRodListener created INFO: Listener: created: key-191 May 30, 2018 9:56:25 AM org.mposolda.ClientListenerFailoverTest$HotRodListener created INFO: Listener: created: key-191 May 30, 2018 9:56:26 AM org.mposolda.ClientListenerFailoverTest main INFO: Adding key: key-192 May 30, 2018 9:56:26 AM org.mposolda.ClientListenerFailoverTest$HotRodListener created INFO: Listener: created: key-192 May 30, 2018 9:56:26 AM org.mposolda.ClientListenerFailoverTest$HotRodListener created INFO: Listener: created: key-192 ... {code} Sorry for the brittle steps to reproduce with the need of debugger, but that was the only way to simulate it reliably. Without debugger, the listener is usually re-registered once (correct behaviour), but sometimes twice (incorrect behaviour), so I think some issue is here. was: I was not able to reliably reproduce why the client listener is re-registered twice without debugger. I've needed to use the debugger and this helps to reliable reproduce it in my environment. 1) Unzip infinispan-server 9.2.1.Final and run with: {code} cd infinispan-server-9.2.1.Final/bin/ ./standalone.sh -c clustered.xml {code} 2) Run this Java application from IDE in debug mode https://github.com/mposolda/misc/blob/master/ispn-client-listener/src/mai... . Make sure that infinispan version (Version of infinispan on client side) is 9.2.1.Final (property "ispn.version" in this file: https://github.com/mposolda/misc/blob/master/ispn-client-listener/pom.xml After application is executed, you can see that items are added and client listener is triggered as expected: {code} May 30, 2018 9:53:12 AM org.mposolda.ClientListenerFailoverTest main INFO: RemoteCache created May 30, 2018 9:53:13 AM org.mposolda.ClientListenerFailoverTest main INFO: Adding key: key-0 May 30, 2018 9:53:13 AM org.mposolda.ClientListenerFailoverTest$HotRodListener created INFO: Listener: created: key-0 May 30, 2018 9:53:14 AM org.mposolda.ClientListenerFailoverTest main INFO: Adding key: key-1 May 30, 2018 9:53:14 AM org.mposolda.ClientListenerFailoverTest$HotRodListener created INFO: Listener: created: key-1 May 30, 2018 9:53:15 AM org.mposolda.ClientListenerFailoverTest main INFO: Adding key: key-2 May 30, 2018 9:53:15 AM org.mposolda.ClientListenerFailoverTest$HotRodListener created INFO: Listener: created: key-2 May 30, 2018 9:53:16 AM org.mposolda.ClientListenerFailoverTest main INFO: Adding key: key-3 May 30, 2018 9:53:16 AM org.mposolda.ClientListenerFailoverTest$HotRodListener created INFO: Listener: created: key-3 May 30, 2018 9:53:17 AM org.mposolda.ClientListenerFailoverTest main INFO: Adding key: key-4 May 30, 2018 9:53:17 AM org.mposolda.ClientListenerFailoverTest$HotRodListener created INFO: Listener: created: key-4 May 30, 2018 9:53:18 AM org.mposolda.ClientListenerFailoverTest main INFO: Adding key: key-5 May 30, 2018 9:53:18 AM org.mposolda.ClientListenerFailoverTest$HotRodListener created INFO: Listener: created: key-5 .... {code} 3) Add breakpoint to class org.infinispan.client.hotrod.impl.operations.AddClientListenerOperation to the beginning of method "execute(Channel channel) 4) Restart infinispan-server 5) After server is restarted, the method AddClientListenerOperation.execute is invoked. Wait with breakpoint at least 10 seconds to reproduce the issue. 6) Continue with breakpoint and see that method is executed another time. Continue with breakpoint again. 7) Now I can see that clientListener is executed twice for each added item, which is NOT ok. {code} .... INFO: Adding key: key-189 May 30, 2018 9:56:23 AM org.mposolda.ClientListenerFailoverTest$HotRodListener created INFO: Listener: created: key-189 May 30, 2018 9:56:23 AM org.mposolda.ClientListenerFailoverTest$HotRodListener created INFO: Listener: created: key-189 May 30, 2018 9:56:24 AM org.mposolda.ClientListenerFailoverTest main INFO: Adding key: key-190 May 30, 2018 9:56:24 AM org.mposolda.ClientListenerFailoverTest$HotRodListener created INFO: Listener: created: key-190 May 30, 2018 9:56:24 AM org.mposolda.ClientListenerFailoverTest$HotRodListener created INFO: Listener: created: key-190 May 30, 2018 9:56:25 AM org.mposolda.ClientListenerFailoverTest main INFO: Adding key: key-191 May 30, 2018 9:56:25 AM org.mposolda.ClientListenerFailoverTest$HotRodListener created INFO: Listener: created: key-191 May 30, 2018 9:56:25 AM org.mposolda.ClientListenerFailoverTest$HotRodListener created INFO: Listener: created: key-191 May 30, 2018 9:56:26 AM org.mposolda.ClientListenerFailoverTest main INFO: Adding key: key-192 May 30, 2018 9:56:26 AM org.mposolda.ClientListenerFailoverTest$HotRodListener created INFO: Listener: created: key-192 May 30, 2018 9:56:26 AM org.mposolda.ClientListenerFailoverTest$HotRodListener created INFO: Listener: created: key-192 ... {code} Sorry for the brittle steps to reproduce with the need of debugger, but that was the only way to simulate it reliably. Without debugger, the listener is usually re-registered once (correct behaviour), but sometimes twice (incorrect behaviour), so I think some issue is here. > Client listeners are sometimes re-registered twice after infinispan-server restart > ---------------------------------------------------------------------------------- > > Key: ISPN-9220 > URL: https://issues.jboss.org/browse/ISPN-9220 > Project: Infinispan > Issue Type: Bug > Components: Hot Rod > Affects Versions: 9.2.1.Final > Reporter: Marek Posolda > > During test of summit, we saw some issue with client listeners. Setup was this: > - Every site had one hotrod client (RHSSO), which used infinispan of version 8.2.8.Final and one infinispan-server, which I think was version 9.2.1.Final > - Client (RH-SSO) had some client listener registered against remoteCache > - After restart of infinispan-server, the RH-SSO was able to re-connect to it and CRUD the items to the remoteCache. But previously registered clientListeners were lost. > Note that setup demo used just 1 infinispan-server on every site, so there were not any topology changes (no possibility of re-balance client listener to other node). > I've tried to do simple reproducer for the scenario above and verified that with client 8.2.8.Final and server 9.2.1.Final, the client listener is not automatically re-registered after restart. > BUT after upgrade client to 9.2.1.Final, re-registration worked fine and client listener was re-registered automatically. This is important as from long term perspective, we are upgrading to infinispan 9 on RH-SSO side. But I had the opposite issue, that sometimes the client listener is registered twice. See steps to reproduce for the details. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9220) Client listeners are sometimes re-registered twice after infinispan-server restart

by Marek Posolda (JIRA)

Marek Posolda created ISPN-9220: ----------------------------------- Summary: Client listeners are sometimes re-registered twice after infinispan-server restart Key: ISPN-9220 URL: https://issues.jboss.org/browse/ISPN-9220 Project: Infinispan Issue Type: Bug Components: Hot Rod Affects Versions: 9.2.1.Final Reporter: Marek Posolda During test of summit, we saw some issue with client listeners. Setup was this: - Every site had one hotrod client (RHSSO), which used infinispan of version 8.2.8.Final and one infinispan-server, which I think was version 9.2.1.Final - Client (RH-SSO) had some client listener registered against remoteCache - After restart of infinispan-server, the RH-SSO was able to re-connect to it and CRUD the items to the remoteCache. But previously registered clientListeners were lost. Note that setup demo used just 1 infinispan-server on every site, so there were not any topology changes (no possibility of re-balance client listener to other node). I've tried to do simple reproducer for the scenario above and verified that with client 8.2.8.Final and server 9.2.1.Final, the client listener is not automatically re-registered after restart. BUT after upgrade client to 9.2.1.Final, re-registration worked fine and client listener was re-registered automatically. This is important as from long term perspective, we are upgrading to infinispan 9 on RH-SSO side. But I had the opposite issue, that sometimes the client listener is registered twice. See steps to reproduce for the details. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2018