[JBoss JIRA] (ISPN-7418) Add per-cache key/value type information
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-7418?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes edited comment on ISPN-7418 at 5/9/17 3:28 AM:
-----------------------------------------------------------------
bq. This part of the transcoding enhancement is related to the changes required to the core cache code to force the cache to store keys and values of a certain type.
bq. The type information should be defined via a MIME type, and should be configured by the user.
Not sure if the …
[View More]user will be able to force it. Consider a cache that is configured with MimeType "text/plain; charset=UTF-8". The following scenarios will prevent the cache from storing plain text:
* When using OFF_HEAP: keys and values must be byte[ ] with a WrappedByteArray around it.
* When using Remote Query: keys must be byte[ ] and values must be ProtobufValueWrapper (which wraps the byte[ ]), and the byte[ ] must be protobuf encoded.
* When using the server: keys and values should be byte[ ] to avoid back and forth conversions.
* When using script: scripts have a metadata header that allows for plain text, but it assumes storage is done via byte[ ] obtained from String.getBytes(charset) and it currently does conversions back and forth.
was (Author: gustavonalle):
| This part of the transcoding enhancement is related to the changes required to the core cache code to force the cache to store keys and values of a certain type.
| The type information should be defined via a MIME type, and should be configured by the user.
Not sure if the user will be able to force it. Consider a cache that is configured with MimeType "text/plain; charset=UTF-8". The following scenarios will prevent the cache from storing plain text:
* When using OFF_HEAP: keys and values must be byte[ ] with a WrappedByteArray around it.
* When using Remote Query: keys must be byte[ ] and values must be ProtobufValueWrapper (which wraps the byte[ ]), and the byte[ ] must be protobuf encoded.
* When using the server: keys and values should be byte[ ] to avoid back and forth conversions.
* When using script: scripts have a metadata header that allows for plain text, but it assumes storage is done via byte[ ] obtained from String.getBytes(charset) and it currently does conversions back and forth.
> Add per-cache key/value type information
> ----------------------------------------
>
> Key: ISPN-7418
> URL: https://issues.jboss.org/browse/ISPN-7418
> Project: Infinispan
> Issue Type: Sub-task
> Reporter: Galder Zamarreño
>
> This part of the transcoding enhancement is related to the changes required to the core cache code to force the cache to store keys and values of a certain type.
> The type information should be defined via a MIME type, and should be configured by the user.
> A cache can only have a single key+value type combination. A single cache will not support storing data of different key and/or value types. Amongst other reasons, this is done for space efficiency.
> Once a cache can be configured with a specific key and value type, the user should be able to retrieve the value with an alternative MIME type. Behind the scenes, the cache should be able to transform the value from the give type to target type on the fly.
> As suggested in the wiki, there should be the possibility for the key/value type to be implicitly determined by the key+value type passed in during the first cache write. The aim of this is to enable remote clients to decide what the key+value type are upon writing to the cache for the first time, and hence avoid cache pre-configuration.
> Some transcoders might require additional configuration. The cache needs to be able to be configured with the necessary options to do on the fly transcoding for clients. E.g. schema for protobuf...etc.
> An important aspect here is that consistent hashing should not be affected by transcoding.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
[View Less]
7 years, 10 months
[JBoss JIRA] (ISPN-7418) Add per-cache key/value type information
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-7418?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes commented on ISPN-7418:
-----------------------------------------
[~NadirX] [~anistor] Please see the comment above and let me know your thoughts
> Add per-cache key/value type information
> ----------------------------------------
>
> Key: ISPN-7418
> URL: https://issues.jboss.org/browse/ISPN-7418
> Project: Infinispan
> …
[View More] Issue Type: Sub-task
> Reporter: Galder Zamarreño
>
> This part of the transcoding enhancement is related to the changes required to the core cache code to force the cache to store keys and values of a certain type.
> The type information should be defined via a MIME type, and should be configured by the user.
> A cache can only have a single key+value type combination. A single cache will not support storing data of different key and/or value types. Amongst other reasons, this is done for space efficiency.
> Once a cache can be configured with a specific key and value type, the user should be able to retrieve the value with an alternative MIME type. Behind the scenes, the cache should be able to transform the value from the give type to target type on the fly.
> As suggested in the wiki, there should be the possibility for the key/value type to be implicitly determined by the key+value type passed in during the first cache write. The aim of this is to enable remote clients to decide what the key+value type are upon writing to the cache for the first time, and hence avoid cache pre-configuration.
> Some transcoders might require additional configuration. The cache needs to be able to be configured with the necessary options to do on the fly transcoding for clients. E.g. schema for protobuf...etc.
> An important aspect here is that consistent hashing should not be affected by transcoding.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
[View Less]
7 years, 10 months
[JBoss JIRA] (ISPN-7418) Add per-cache key/value type information
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-7418?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes edited comment on ISPN-7418 at 5/9/17 3:00 AM:
-----------------------------------------------------------------
| This part of the transcoding enhancement is related to the changes required to the core cache code to force the cache to store keys and values of a certain type.
| The type information should be defined via a MIME type, and should be configured by the user.
Not sure if the user …
[View More]will be able to force it. Consider a cache that is configured with MimeType "text/plain; charset=UTF-8". The following scenarios will prevent the cache from storing plain text:
* When using OFF_HEAP: keys and values must be byte[ ] with a WrappedByteArray around it.
* When using Remote Query: keys must be byte[ ] and values must be ProtobufValueWrapper (which wraps the byte[ ]), and the byte[ ] must be protobuf encoded.
* When using the server: keys and values should be byte[ ] to avoid back and forth conversions.
* When using script: scripts have a metadata header that allows for plain text, but it assumes storage is done via byte[ ] obtained from String.getBytes(charset) and it currently does conversions back and forth.
was (Author: gustavonalle):
| This part of the transcoding enhancement is related to the changes required to the core cache code to force the cache to store keys and values of a certain type.
| The type information should be defined via a MIME type, and should be configured by the user.
Not sure if the user will be able to force it. Consider a cache that is configured with MimeType "text/plain; charset=UTF8". The following scenarios will prevent the cache from storing plain text:
* When using OFF_HEAP: keys and values must be byte[ ] with a WrappedByteArray around it.
* When using Remote Query: keys must be byte[ ] and values must be ProtobufValueWrapper (which wraps the byte[ ]), and the byte[ ] must be protobuf encoded.
* When using the server: keys and values should be byte[ ] to avoid back and forth conversions.
* When using script: scripts have a metadata header that allows for plain text, but it assumes storage is done via byte[ ] obtained from String.getBytes(charset) and it currently does conversions back and forth.
> Add per-cache key/value type information
> ----------------------------------------
>
> Key: ISPN-7418
> URL: https://issues.jboss.org/browse/ISPN-7418
> Project: Infinispan
> Issue Type: Sub-task
> Reporter: Galder Zamarreño
>
> This part of the transcoding enhancement is related to the changes required to the core cache code to force the cache to store keys and values of a certain type.
> The type information should be defined via a MIME type, and should be configured by the user.
> A cache can only have a single key+value type combination. A single cache will not support storing data of different key and/or value types. Amongst other reasons, this is done for space efficiency.
> Once a cache can be configured with a specific key and value type, the user should be able to retrieve the value with an alternative MIME type. Behind the scenes, the cache should be able to transform the value from the give type to target type on the fly.
> As suggested in the wiki, there should be the possibility for the key/value type to be implicitly determined by the key+value type passed in during the first cache write. The aim of this is to enable remote clients to decide what the key+value type are upon writing to the cache for the first time, and hence avoid cache pre-configuration.
> Some transcoders might require additional configuration. The cache needs to be able to be configured with the necessary options to do on the fly transcoding for clients. E.g. schema for protobuf...etc.
> An important aspect here is that consistent hashing should not be affected by transcoding.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
[View Less]
7 years, 10 months
[JBoss JIRA] (ISPN-7418) Add per-cache key/value type information
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-7418?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes edited comment on ISPN-7418 at 5/9/17 3:00 AM:
-----------------------------------------------------------------
| This part of the transcoding enhancement is related to the changes required to the core cache code to force the cache to store keys and values of a certain type.
| The type information should be defined via a MIME type, and should be configured by the user.
Not sure if the user …
[View More]will be able to force it. Consider a cache that is configured with MimeType "text/plain; charset=UTF8". The following scenarios will prevent the cache from storing plain text:
* When using OFF_HEAP: keys and values must be byte[ ] with a WrappedByteArray around it.
* When using Remote Query: keys must be byte[ ] and values must be ProtobufValueWrapper (which wraps the byte[ ]), and the byte[ ] must be protobuf encoded.
* When using the server: keys and values should be byte[ ] to avoid back and forth conversions.
* When using script: scripts have a metadata header that allows for plain text, but it assumes storage is done via byte[ ] obtained from String.getBytes(charset) and it currently does conversions back and forth.
was (Author: gustavonalle):
| This part of the transcoding enhancement is related to the changes required to the core cache code to force the cache to store keys and values of a certain type.
Not sure if the user will be able to force it. Consider a cache that is configured with MimeType "text/plain; charset=UTF8". The following scenarios will prevent the cache from storing plain text:
* When using OFF_HEAP: keys and values must be byte[ ] with a WrappedByteArray around it.
* When using Remote Query: keys must be byte[ ] and values must be ProtobufValueWrapper (which wraps the byte[ ]), and the byte[ ] must be protobuf encoded.
* When using the server: keys and values should be byte[ ] to avoid back and forth conversions.
* When using script: scripts have a metadata header that allows for plain text, but it assumes storage is done via byte[ ] obtained from String.getBytes(charset) and it currently does conversions back and forth.
> Add per-cache key/value type information
> ----------------------------------------
>
> Key: ISPN-7418
> URL: https://issues.jboss.org/browse/ISPN-7418
> Project: Infinispan
> Issue Type: Sub-task
> Reporter: Galder Zamarreño
>
> This part of the transcoding enhancement is related to the changes required to the core cache code to force the cache to store keys and values of a certain type.
> The type information should be defined via a MIME type, and should be configured by the user.
> A cache can only have a single key+value type combination. A single cache will not support storing data of different key and/or value types. Amongst other reasons, this is done for space efficiency.
> Once a cache can be configured with a specific key and value type, the user should be able to retrieve the value with an alternative MIME type. Behind the scenes, the cache should be able to transform the value from the give type to target type on the fly.
> As suggested in the wiki, there should be the possibility for the key/value type to be implicitly determined by the key+value type passed in during the first cache write. The aim of this is to enable remote clients to decide what the key+value type are upon writing to the cache for the first time, and hence avoid cache pre-configuration.
> Some transcoders might require additional configuration. The cache needs to be able to be configured with the necessary options to do on the fly transcoding for clients. E.g. schema for protobuf...etc.
> An important aspect here is that consistent hashing should not be affected by transcoding.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
[View Less]
7 years, 10 months
[JBoss JIRA] (ISPN-7418) Add per-cache key/value type information
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-7418?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes commented on ISPN-7418:
-----------------------------------------
| This part of the transcoding enhancement is related to the changes required to the core cache code to force the cache to store keys and values of a certain type.
Not sure if the user will be able to force it. Consider a cache that is configured with MimeType "text/plain; charset=UTF8". The following scenarios will prevent the …
[View More]cache from storing plain text:
* When using OFF_HEAP: keys and values must be byte[ ] with a WrappedByteArray around it.
* When using Remote Query: keys must be byte[ ] and values must be ProtobufValueWrapper (which wraps the byte[ ]), and the byte[ ] must be protobuf encoded.
* When using the server: keys and values should be byte[ ] to avoid back and forth conversions.
* When using script: scripts have a metadata header that allows for plain text, but it assumes storage is done via byte[ ] obtained from String.getBytes(charset) and it currently does conversions back and forth.
> Add per-cache key/value type information
> ----------------------------------------
>
> Key: ISPN-7418
> URL: https://issues.jboss.org/browse/ISPN-7418
> Project: Infinispan
> Issue Type: Sub-task
> Reporter: Galder Zamarreño
>
> This part of the transcoding enhancement is related to the changes required to the core cache code to force the cache to store keys and values of a certain type.
> The type information should be defined via a MIME type, and should be configured by the user.
> A cache can only have a single key+value type combination. A single cache will not support storing data of different key and/or value types. Amongst other reasons, this is done for space efficiency.
> Once a cache can be configured with a specific key and value type, the user should be able to retrieve the value with an alternative MIME type. Behind the scenes, the cache should be able to transform the value from the give type to target type on the fly.
> As suggested in the wiki, there should be the possibility for the key/value type to be implicitly determined by the key+value type passed in during the first cache write. The aim of this is to enable remote clients to decide what the key+value type are upon writing to the cache for the first time, and hence avoid cache pre-configuration.
> Some transcoders might require additional configuration. The cache needs to be able to be configured with the necessary options to do on the fly transcoding for clients. E.g. schema for protobuf...etc.
> An important aspect here is that consistent hashing should not be affected by transcoding.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
[View Less]
7 years, 10 months
[JBoss JIRA] (ISPN-5655) MissingFormatArgumentException thrown by PreferConsistencyStrategy
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5655?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5655:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1412752|https://bugzilla.redhat.com/show_bug.cgi?id=1412752] from ASSIGNED to POST
> MissingFormatArgumentException thrown by PreferConsistencyStrategy
> ------------------------------------------------------------------
>
> …
[View More] Key: ISPN-5655
> URL: https://issues.jboss.org/browse/ISPN-5655
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 8.0.0.Beta2
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Fix For: 8.0.0.Beta3, 8.0.0.Final
>
>
> Exception thrown due to line 197 in PreferConsistencyStrategy.java
> 2015-08-03 10:30:38,873 ERROR Unable to format msg: After merge, cache %s has recovered and is entering available mode java.util.MissingFormatArgumentException: Format specifier '%s'
> at java.util.Formatter.format(Formatter.java:2519)
> at java.util.Formatter.format(Formatter.java:2455)
> at java.lang.String.format(String.java:2928)
> at org.apache.logging.log4j.message.StringFormattedMessage.formatMessage(StringFormattedMessage.java:88)
> at org.apache.logging.log4j.message.StringFormattedMessage.getFormattedMessage(StringFormattedMessage.java:60)
> at org.apache.logging.log4j.core.pattern.MessagePatternConverter.format(MessagePatternConverter.java:68)
> at org.apache.logging.log4j.core.pattern.PatternFormatter.format(PatternFormatter.java:36)
> at org.apache.logging.log4j.core.layout.PatternLayout.toSerializable(PatternLayout.java:196)
> at org.apache.logging.log4j.core.layout.PatternLayout.toSerializable(PatternLayout.java:55)
> at org.apache.logging.log4j.core.layout.AbstractStringLayout.toByteArray(AbstractStringLayout.java:71)
> at org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.append(AbstractOutputStreamAppender.java:108)
> at org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:99)
> at org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:430)
> at org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:409)
> at org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:412)
> at org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:367)
> at org.apache.logging.log4j.core.Logger.logMessage(Logger.java:112)
> at org.jboss.logging.Log4j2Logger.doLogf(Log4j2Logger.java:66)
> at org.jboss.logging.Logger.logf(Logger.java:2445)
> at org.jboss.logging.DelegatingBasicLogger.debugf(DelegatingBasicLogger.java:344)
> at org.infinispan.partitionhandling.impl.PreferConsistencyStrategy.onPartitionMerge(PreferConsistencyStrategy.java:198)
> at org.infinispan.topology.ClusterCacheStatus.doMergePartitions(ClusterCacheStatus.java:509)
> at org.infinispan.topology.ClusterTopologyManagerImpl$2.call(ClusterTopologyManagerImpl.java:383)
> at org.infinispan.topology.ClusterTopologyManagerImpl$2.call(ClusterTopologyManagerImpl.java:380)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at org.infinispan.executors.SemaphoreCompletionService$QueueingTask.runInternal(SemaphoreCompletionService.java:173)
> at org.infinispan.executors.SemaphoreCompletionService$QueueingTask.run(SemaphoreCompletionService.java:151)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
[View Less]
7 years, 10 months
[JBoss JIRA] (ISPN-7808) Upgrade to mockito 2.7.21
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-7808?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-7808:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Upgrade to mockito 2.7.21
> -------------------------
>
> Key: ISPN-7808
> URL: https://issues.jboss.org/browse/ISPN-7808
> Project: Infinispan
> Issue Type: Component Upgrade
> …
[View More]Components: Test Suite - Core, Test Suite - Server
> Affects Versions: 9.0.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 9.1.0.Alpha1
>
>
> While fixing ISPN-7659, I changed {{version.mockito}} in the parent POM to 2.7.21 (the latest version of mockito-core).
> It turns out that all the modules actually depend on {{mockito-all}} without specifying a version. {{version.mockito}} was only used by some OSGi integration tests, and the change broke them.
> The latest version of mockito-all is 1.9.5, which is quite old, so it would be best to upgrade to the latest mockito-core everywhere.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
[View Less]
7 years, 10 months
[JBoss JIRA] (ISPN-7418) Add per-cache key/value type information
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-7418?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-7418:
------------------------------------
Forum Reference: https://github.com/infinispan/infinispan-designs/blob/master/Compatibilit... (was: https://github.com/infinispan/infinispan/wiki/Compatibility-2.0)
> Add per-cache key/value type information
> ----------------------------------------
>
> Key: ISPN-7418
> URL: https://…
[View More]issues.jboss.org/browse/ISPN-7418
> Project: Infinispan
> Issue Type: Sub-task
> Reporter: Galder Zamarreño
>
> This part of the transcoding enhancement is related to the changes required to the core cache code to force the cache to store keys and values of a certain type.
> The type information should be defined via a MIME type, and should be configured by the user.
> A cache can only have a single key+value type combination. A single cache will not support storing data of different key and/or value types. Amongst other reasons, this is done for space efficiency.
> Once a cache can be configured with a specific key and value type, the user should be able to retrieve the value with an alternative MIME type. Behind the scenes, the cache should be able to transform the value from the give type to target type on the fly.
> As suggested in the wiki, there should be the possibility for the key/value type to be implicitly determined by the key+value type passed in during the first cache write. The aim of this is to enable remote clients to decide what the key+value type are upon writing to the cache for the first time, and hence avoid cache pre-configuration.
> Some transcoders might require additional configuration. The cache needs to be able to be configured with the necessary options to do on the fly transcoding for clients. E.g. schema for protobuf...etc.
> An important aspect here is that consistent hashing should not be affected by transcoding.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
[View Less]
7 years, 10 months
[JBoss JIRA] (ISPN-375) Enable Hot Rod clients to start transactions
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-375?page=com.atlassian.jira.plugin.s... ]
Tristan Tarrant reassigned ISPN-375:
------------------------------------
Assignee: Pedro Ruivo
> Enable Hot Rod clients to start transactions
> --------------------------------------------
>
> Key: ISPN-375
> URL: https://issues.jboss.org/browse/ISPN-375
> Project: Infinispan
> Issue Type: Feature Request
> Components: …
[View More]Remote Protocols
> Reporter: Galder Zamarreño
> Assignee: Pedro Ruivo
> Priority: Blocker
> Labels: hackathon
>
> It might be useful to allow Hot Rod clients to start transactions within Hot Rod servers. The possibility of clients participating in the actual transaction, i.e. being an XAResource, should not be imposed since this might be less than trivial to achieve in non-Java environments. The alternative would be to allow clients to start Hot Rod server local transactions only.
> This would require enhancing Hot Rod spec to have some begin/commit/rollback commands that return a tx id, and for clients to be able to send this id as part of each command that should participate in the transaction.
> Pitfalls to avoid include avoiding a transaction to be propagated over several Hot Rod servers. IOW, to simplify things, if a tx is started in server A, all ops within that tx should be directed to tx. Load balancing could still happen but would need to be tx sticky.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
[View Less]
7 years, 10 months