[JBoss JIRA] (ISPN-9604) Support for converters in the request format
by Gustavo Fernandes (Jira)
Gustavo Fernandes created ISPN-9604:
---------------------------------------
Summary: Support for converters in the request format
Key: ISPN-9604
URL: https://issues.jboss.org/browse/ISPN-9604
Project: Infinispan
Issue Type: Feature Request
Components: Listeners, Remote Protocols
Affects Versions: 9.4.0.Final
Reporter: Gustavo Fernandes
Assignee: Gustavo Fernandes
As described in the [docs|http://infinispan.org/docs/stable/user_guide/user_guide.html#event_m...], a filter/converter can optionally specify a {{MediaType}} to process events, and let Infinispan perform the conversion between the storage format and the chosen format. The last step, in case it's needed, it to convert the event to the request format, which is the format that the cache was decorated with the {{withMediaType(...)}} method when the listener registration was performed.
Some converters, such as {{org.infinispan.server.hotrod.KeyValueVersionConverter}} (used in NearCache and the Spark Connecor) cannot work in this scheme since as part of its operation, it reads the stored key and values and creates a new value which is the aggregation of the Key and the Value in the byte[] format, thus preventing the final transformation step to the request mediatype.
For this case it'd be interesting to have the possibility of applying the converters's convert() operation *after* having transformed the Key and Values to the final request format, therefore the final event value will be an aggregated byte[] but in the user requested format.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (ISPN-9604) Support to run converters in the user requested format
by Gustavo Fernandes (Jira)
[ https://issues.jboss.org/browse/ISPN-9604?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-9604:
------------------------------------
Summary: Support to run converters in the user requested format (was: Support for converters in the request format)
> Support to run converters in the user requested format
> ------------------------------------------------------
>
> Key: ISPN-9604
> URL: https://issues.jboss.org/browse/ISPN-9604
> Project: Infinispan
> Issue Type: Feature Request
> Components: Listeners, Remote Protocols
> Affects Versions: 9.4.0.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Major
>
> As described in the [docs|http://infinispan.org/docs/stable/user_guide/user_guide.html#event_m...], a filter/converter can optionally specify a {{MediaType}} to process events, and let Infinispan perform the conversion between the storage format and the chosen format. The last step, in case it's needed, it to convert the event to the request format, which is the format that the cache was decorated with the {{withMediaType(...)}} method when the listener registration was performed.
> Some converters, such as {{org.infinispan.server.hotrod.KeyValueVersionConverter}} (used in NearCache and the Spark Connecor) cannot work in this scheme since as part of its operation, it reads the stored key and values and creates a new value which is the aggregation of the Key and the Value in the byte[] format, thus preventing the final transformation step to the request mediatype.
> For this case it'd be interesting to have the possibility of applying the converters's convert() operation *after* having transformed the Key and Values to the final request format, therefore the final event value will be an aggregated byte[] but in the user requested format.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (ISPN-9483) TEST_PING doesn't trigger merge after JGroups 4.0.13 upgrade
by Diego Lovison (Jira)
[ https://issues.jboss.org/browse/ISPN-9483?page=com.atlassian.jira.plugin.... ]
Diego Lovison updated ISPN-9483:
--------------------------------
Labels: on-hold testsuite_stability (was: testsuite_stability)
> TEST_PING doesn't trigger merge after JGroups 4.0.13 upgrade
> ------------------------------------------------------------
>
> Key: ISPN-9483
> URL: https://issues.jboss.org/browse/ISPN-9483
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 9.4.0.CR1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Labels: on-hold, testsuite_stability
> Fix For: 9.4.0.CR3
>
>
> In JGroups 4.0.13.Final, {{MERGE3}} started using the {{ASYNC_DISCOVERY_EVENT}} to find other members. {{TEST_PING}} doesn't handle the event correctly, at least when trace logging is enabled, and the merge never happens.
> {{Discovery}} should handle the new event automatically, but it only works if the discovery protocol actively sends out {{GET_MBRS_REQ}} messages and receives {{GET_MBRS_RSP}} messages from other members. {{TEST_PING}} doesn't receive any {{GET_MBRS_RSP}} messages, so {{Discovery.addResponse()}} is never called.
> This causes failures in all the tests that split the cluster and heal it, but for some reason CI isn't reporting the failures:
> {noformat}
> [OK: 70, KO: 1, SKIP: 0] Test failed: org.infinispan.distribution.rehash.RehashAfterPartitionMergeTest.testCachePartition[DIST_SYNC]
> java.lang.RuntimeException: Timed out before caches had changed views ([[RehashAfterPartitionMergeTest[DIST_SYNC]-NodeB-45390], [RehashAfterPartitionMergeTest[DIST_SYNC]-NodeD-46782]]) to contain 2 members
> at org.infinispan.test.TestingUtil.blockUntilViewsChanged(TestingUtil.java:761)
> at org.infinispan.test.TestingUtil.blockUntilViewsChanged(TestingUtil.java:743)
> at org.infinispan.distribution.rehash.RehashAfterPartitionMergeTest.testCachePartition(RehashAfterPartitionMergeTest.java:67)
> {noformat}
> https://ci.infinispan.org/job/Infinispan/job/master/808/consoleFull
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (ISPN-9323) RemoteCache.getWithMetadata returns expired metadata when server is transactional cache
by William Burns (Jira)
[ https://issues.jboss.org/browse/ISPN-9323?page=com.atlassian.jira.plugin.... ]
William Burns edited comment on ISPN-9323 at 10/11/18 1:20 PM:
---------------------------------------------------------------
Hrmm *InternalMetdataImpl.isExpired(long)* wouldn't return true if created and lifespan were both 0. And technically the store shouldn't be checking if the entry is expired anyways, as *getWithMetadata* would never return an expired entry in the first place.
So as a simple workaround I would not be checking these values at all. Unless you are doing some custom work based on these values elsewhere?
Either way we can try to fix these values as they should be consistent (this is a known issue, just wasn't thought to be that important at the time).
was (Author: william.burns):
Hrmm *InternalMetdataImpl.isExpired(long)* wouldn't return true if created and lifespan were both 0. And technically the store shouldn't be checking if the entry is expired anyways, as *getWithMetadata* would never return an expired entry in the first place.
> 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.2.4.Final, 9.4.0.Final, 9.3.1.Final
> Reporter: Marek Posolda
> Assignee: William Burns
> Priority: Major
> 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.12.1#712002)
7 years, 6 months
[JBoss JIRA] (ISPN-9323) RemoteCache.getWithMetadata returns expired metadata when server is transactional cache
by William Burns (Jira)
[ https://issues.jboss.org/browse/ISPN-9323?page=com.atlassian.jira.plugin.... ]
William Burns edited comment on ISPN-9323 at 10/11/18 1:19 PM:
---------------------------------------------------------------
Hrmm *InternalMetdataImpl.isExpired(long)* wouldn't return true if created and lifespan were both 0. And technically the store shouldn't be checking if the entry is expired anyways, as *getWithMetadata* would never return an expired entry in the first place.
was (Author: william.burns):
Hrmm InternalMetdataImpl.isExpired(long) wouldn't return true if created and lifespan were both 0. And technically the store shouldn't be checking if the entry is expired anyways, as `getWithMetadata`
> 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.2.4.Final, 9.4.0.Final, 9.3.1.Final
> Reporter: Marek Posolda
> Assignee: William Burns
> Priority: Major
> 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.12.1#712002)
7 years, 6 months
[JBoss JIRA] (ISPN-9323) RemoteCache.getWithMetadata returns expired metadata when server is transactional cache
by William Burns (Jira)
[ https://issues.jboss.org/browse/ISPN-9323?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-9323:
-------------------------------------
Hrmm InternalMetdataImpl.isExpired(long) wouldn't return true if created and lifespan were both 0. And technically the store shouldn't be checking if the entry is expired anyways, as `getWithMetadata`
> 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.2.4.Final, 9.4.0.Final, 9.3.1.Final
> Reporter: Marek Posolda
> Assignee: William Burns
> Priority: Major
> 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.12.1#712002)
7 years, 6 months
[JBoss JIRA] (ISPN-7087) Handle ClientCacheEntryExpired into InvalidatedNearCacheListener
by William Burns (Jira)
[ https://issues.jboss.org/browse/ISPN-7087?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-7087:
--------------------------------
Fix Version/s: 9.4.1.Final
10.0.0.Alpha1
> Handle ClientCacheEntryExpired into InvalidatedNearCacheListener
> ----------------------------------------------------------------
>
> Key: ISPN-7087
> URL: https://issues.jboss.org/browse/ISPN-7087
> Project: Infinispan
> Issue Type: Enhancement
> Components: Remote Protocols
> Affects Versions: 8.2.4.Final
> Reporter: Jean-Francois LARTAUD
> Assignee: William Burns
> Priority: Major
> Fix For: 9.4.1.Final, 10.0.0.Alpha1
>
>
> Hi,
> Is there a reason why the InvalidatedNearCacheListener does not support the cache entry expiration ?
> By adding the ClientCacheEntryExpired annotation on the listener, it should be possible to invalidate a near cache entry when it has expired on a remote infinispan server.
> For example, into org.infinispan.client.hotrod.near.NearCacheService.InvalidatedNearCacheListener add this method :
> {code}
> @ClientCacheEntryExpired
> @SuppressWarnings("unused")
> public void handleExpiredEvent(ClientCacheEntryExpiredEvent<K> event) {
> invalidate(event.getKey());
> }
> {code}
> Thanks,
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (ISPN-7087) Handle ClientCacheEntryExpired into InvalidatedNearCacheListener
by William Burns (Jira)
[ https://issues.jboss.org/browse/ISPN-7087?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-7087:
--------------------------------
Status: Open (was: New)
> Handle ClientCacheEntryExpired into InvalidatedNearCacheListener
> ----------------------------------------------------------------
>
> Key: ISPN-7087
> URL: https://issues.jboss.org/browse/ISPN-7087
> Project: Infinispan
> Issue Type: Enhancement
> Components: Remote Protocols
> Affects Versions: 8.2.4.Final
> Reporter: Jean-Francois LARTAUD
> Priority: Major
>
> Hi,
> Is there a reason why the InvalidatedNearCacheListener does not support the cache entry expiration ?
> By adding the ClientCacheEntryExpired annotation on the listener, it should be possible to invalidate a near cache entry when it has expired on a remote infinispan server.
> For example, into org.infinispan.client.hotrod.near.NearCacheService.InvalidatedNearCacheListener add this method :
> {code}
> @ClientCacheEntryExpired
> @SuppressWarnings("unused")
> public void handleExpiredEvent(ClientCacheEntryExpiredEvent<K> event) {
> invalidate(event.getKey());
> }
> {code}
> Thanks,
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months