[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 commented on ISPN-9323:
-------------------------------------
[~william.burns] Thanks for looking into this. I've just did some more testing. With infinispan-server and client both at version 9.2.4.Final, the behaviour was that if you call this:
{code}
remoteCache.put("key", "value", 1000, TimeUnit.SECONDS, 100, TimeUnit.SECONDS);
{code}
And then you call this:
{code}
org.infinispan.Cache cacheBackedByRemoteStore = getCacheBackedByRemoteStore("localhost", 11222);
Object result = cacheBackedByRemoteStore.get("key");
{code}
the result was null. And I identified the reason was the fact that "created" and "lastUsed" were both 0 and hence remoteStore/persistenceManager treated the entry from remoteCache as expired.
I've checked that in 9.3.1.Final and 9.4.0.Final, this behaviour changed and the "result" will be correctly set.
In shortcut: I am happy now :) In other words, "created" and "lastUsed" returned in the remoteCache metadata are still 0, but it seems something changed in the implementation of remoteStore/persistenceManager as it doesn't treat this entry from remoteCache to be expired anymore.
The "created" and "lastUsed" are not important for my use-case as long as remoteStore works correctly. Leaving this JIRA open just for the case if someone else wants to have fix for "created" and "lastUsed" in the metadata. But not a priority for me anymore.
> 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-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:
------------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/6334
> 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. Once converters are applied, 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.
> This is the basic mechanism that allow events to be received in a different MediaType than the data is stored, at the same time allowing the filter/converter to pick the best format to process data.
> 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 requested mediatype, since the type information is totally lost in the process.
> 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:
------------------------------------
Status: Open (was: New)
> 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. Once converters are applied, 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.
> This is the basic mechanism that allow events to be received in a different MediaType than the data is stored, at the same time allowing the filter/converter to pick the best format to process data.
> 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 requested mediatype, since the type information is totally lost in the process.
> 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-9605) Remove extraneous code related to eager near cache
by William Burns (Jira)
William Burns created ISPN-9605:
-----------------------------------
Summary: Remove extraneous code related to eager near cache
Key: ISPN-9605
URL: https://issues.jboss.org/browse/ISPN-9605
Project: Infinispan
Issue Type: Sub-task
Components: Listeners
Reporter: William Burns
Fix For: 10.0.0.Final
Eager near caching ended up sending too much data across the socket and thus we removed it in favor of only invalidated near caching. We should remove the old code lying around, such as in NearCacheService.
--
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:
------------------------------------
Description:
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. Once converters are applied, 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.
This is the basic mechanism that allow events to be received in a different MediaType than the data is stored, at the same time allowing the filter/converter to pick the best format to process data.
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 requested mediatype, since the type information is totally lost in the process.
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.
was:
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. Once converters are applied, 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.
This is the basic mechanism that allow events to be received in a different MediaType than the data is stored, at the same time allowing the filter/converter to pick the best format to process data.
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.
> 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. Once converters are applied, 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.
> This is the basic mechanism that allow events to be received in a different MediaType than the data is stored, at the same time allowing the filter/converter to pick the best format to process data.
> 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 requested mediatype, since the type information is totally lost in the process.
> 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:
------------------------------------
Description:
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. Once converters are applied, 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.
This is the basic mechanism that allow events to be received in a different MediaType than the data is stored, at the same time allowing the filter/converter to pick the best format to process data.
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.
was:
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. Once converters are applied, 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.
> 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. Once converters are applied, 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.
> This is the basic mechanism that allow events to be received in a different MediaType than the data is stored, at the same time allowing the filter/converter to pick the best format to process data.
> 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:
------------------------------------
Description:
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. Once converters are applied, 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.
was:
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, so that the converter/filter will be presented in the specified 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.
> 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. Once converters are applied, 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:
------------------------------------
Description:
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, so that the converter/filter will be presented in the specified 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.
was:
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.
> 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, so that the converter/filter will be presented in the specified 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