[JBoss JIRA] (ISPN-7409) Replace external marshaller with user marshaller
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-7409?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-7409:
----------------------------------
Sprint: Sprint 9.4.0.Beta1, Sprint 9.4.0.CR1, Sprint 9.4.0.CR3, Sprint 10.0.0.Alpha1 (was: Sprint 9.4.0.Beta1, Sprint 9.4.0.CR1, Sprint 9.4.0.CR3, Sprint 9.4.0.Final)
> Replace external marshaller with user marshaller
> ------------------------------------------------
>
> Key: ISPN-7409
> URL: https://issues.jboss.org/browse/ISPN-7409
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core, Marshalling
> Reporter: Galder Zamarreño
> Assignee: Ryan Emerson
> Fix For: 10.0.0.Final
>
>
> ISPN-6906 brings much needed independence from JBoss Marshalling to our marshalling layer. One of the key aspects it brings it’s the separation between marshalling internal types we know about, e.g. String, byte[], CacheTopologyCommand...etc and external or unknown types, e.g. any types that extend Serializable.
> Although this separation helps achieve objectives of ISPN-6906, it’s not an ideal solution:
> * If user types map directly to primitive types supported by our internal marshaller, or types that depend on types that are marshalled by our internal marshaller, any changes made to the internal marshaller have a direct impact on the representation of the user types.
> * In the ISPN-6906 implementation, Internal marshaller exposes its own externalizer table to the external marshaller so that it can lookup how to marshall internal types. This is done to support corner cases in Hibernate Search where some of the classes that Query module marshalls rely on the fact that some Hibernate Search classes are Serializable, but these classes reference Lucene query classes that are not for which there are externalizers defined. For query logic to work, externalizers have to be found while dealing with Serializable types are being traversed. Gustavo and Sane are aware of this issue and we should soon have externalizers for those Hibernate Search classes and avoid this issue altogether (see ISPN-7156).
> So, rather than an external marshaller, a more suitable abstraction would be to have a user marshaller. The job of the user marshaller, which would be configurable, would be to marshall user types. The user marshaller should be independent of the internal marshaller, so it would not be able to piggyback on the internal externalizers.
> Externalizers for user types could still be supported, by having a user externalizer table, purely used by the user marshaller. In fact, it would make sense that all externalizers that are configured in Infinispan (regardless of whether via xml, programmatic or via annotation) to be user externalizers.
> User types are considered to be:
> * Keys and values
> * Metadata instances provided by the user via *withMetadata() calls
> The benefits of the user marshaller are the following:
> * Having the user marshaller configurable would make it easy to try out different marshallers when comparing how key/value types are marshalled, e.g. try out different ways to marshall Strings.
> * An easier upgrade path for user types. Since user types no longer rely on internal marshaller details, Infinispan upgrades are easier to deal with.
> For reference, custom commands that can be plugged via ModuleCommandFactory implementations would use the internal marshaller since these commands often marshall internal types, e.g. Address.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (ISPN-9209) Implement RemoteCache statistics
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-9209?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9209:
----------------------------------
Sprint: Sprint 9.4.0.CR1, Sprint 9.4.0.CR3 (was: Sprint 9.4.0.CR1, Sprint 9.4.0.CR3, Sprint 9.4.0.Final)
> Implement RemoteCache statistics
> --------------------------------
>
> Key: ISPN-9209
> URL: https://issues.jboss.org/browse/ISPN-9209
> Project: Infinispan
> Issue Type: Enhancement
> Components: Hot Rod
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 9.4.0.CR3
>
>
> The Hot Rod client does not expose any local statistics (RemoteCacheManager.getStatistics() returns the server-side stats).
> We should have the following per-cache stats:
> - remote hits and hit avg time
> - remote misses and miss avg time
> - remote removes and remove avg time
> - near cache hits and avg time
> - near cache miss and avg time
> - near cache size
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (HRJS-76) Hot Rod 2.5 protocol support broken
by Pedro Zapata (JIRA)
[ https://issues.jboss.org/browse/HRJS-76?page=com.atlassian.jira.plugin.sy... ]
Pedro Zapata updated HRJS-76:
-----------------------------
Sprint: Sprint 9.4.0.Final
> Hot Rod 2.5 protocol support broken
> -----------------------------------
>
> Key: HRJS-76
> URL: https://issues.jboss.org/browse/HRJS-76
> Project: Infinispan Javascript client
> Issue Type: Bug
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 0.6.0
>
>
> Trying to run smoke tests with protocol 2.5 results in failure:
> {code}
> rm -drf tmp-tests.log && node node_modules/jasmine-node/lib/jasmine-node/cli.js spec/infinispan_local_spec.js --captureExceptions
> FFFF.FFFFFFFFFFFFTypeError: Cannot read property 'decodeMedia' of undefined
> at decoderMedia (/Users/g/1/infinispan-js-client/lib/protocols.js:73:43)
> at Protocol25.decodeEvent (/Users/g/1/infinispan-js-client/lib/protocols.js:589:28)
> at Socket.onData (/Users/g/1/infinispan-js-client/lib/io.js:121:40)
> at emitOne (events.js:116:13)
> at Socket.emit (events.js:211:7)
> at addChunk (_stream_readable.js:263:12)
> at readableAddChunk (_stream_readable.js:250:11)
> at Socket.Readable.push (_stream_readable.js:208:10)
> at TCP.onread (net.js:597:20)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (ISPN-9520) JSON conversion causes NPE for events
by Gustavo Fernandes (JIRA)
Gustavo Fernandes created ISPN-9520:
---------------------------------------
Summary: JSON conversion causes NPE for events
Key: ISPN-9520
URL: https://issues.jboss.org/browse/ISPN-9520
Project: Infinispan
Issue Type: Bug
Components: Server
Affects Versions: 9.4.0.CR3
Reporter: Gustavo Fernandes
Assignee: Gustavo Fernandes
Fix For: 9.4.0.Final
Since ISPN-9484, all listeners without filter or converter stopped using the value and are using an empty byte[] instead, and the JSON transcoder does not handle it correctly.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (HRJS-77) NPE with 9.4.0.CR3
by Pedro Zapata (JIRA)
[ https://issues.jboss.org/browse/HRJS-77?page=com.atlassian.jira.plugin.sy... ]
Pedro Zapata updated HRJS-77:
-----------------------------
Sprint: Sprint 9.4.0.Final
> NPE with 9.4.0.CR3
> ------------------
>
> Key: HRJS-77
> URL: https://issues.jboss.org/browse/HRJS-77
> Project: Infinispan Javascript client
> Issue Type: Bug
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
>
> NPE when putting data from Node.js client with 9.4.0.CR3.
> {code}
> [Server:server-local] 10:13:52,974 ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (HotRod-ServerIO-8-1) ISPN000136: Error executing command PutKeyValueCommand, writing keys [WrappedByteArray{bytes=[B0x7B226B223A226A6C..[22], hashCode=-1069521542}]: java.lang.NullPointerException
> [Server:server-local] at org.infinispan.server.core.dataconversion.JsonTranscoder.convertTextToJson(JsonTranscoder.java:123)
> [Server:server-local] at org.infinispan.server.core.dataconversion.JsonTranscoder.transcode(JsonTranscoder.java:84)
> [Server:server-local] at org.infinispan.encoding.DataConversion.convertToRequestFormat(DataConversion.java:148)
> [Server:server-local] at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.convertValue(CacheNotifierImpl.java:1852)
> [Server:server-local] at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invokeNoChecks(CacheNotifierImpl.java:1662)
> [Server:server-local] at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1647)
> [Server:server-local] at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryCreated(CacheNotifierImpl.java:395)
> [Server:server-local] at org.infinispan.notifications.cachelistener.NotifyHelper.entryCommitted(NotifyHelper.java:46)
> [Server:server-local] at org.infinispan.interceptors.locking.ClusteringDependentLogic$LocalLogic.commitSingleEntry(ClusteringDependentLogic.java:362)
> [Server:server-local] at org.infinispan.interceptors.locking.ClusteringDependentLogic$AbstractClusteringDependentLogic.commitEntry(ClusteringDependentLogic.java:190)
> [Server:server-local] at org.infinispan.interceptors.impl.EntryWrappingInterceptor.commitContextEntry(EntryWrappingInterceptor.java:584)
> [Server:server-local] at org.infinispan.interceptors.impl.EntryWrappingInterceptor.commitEntryIfNeeded(EntryWrappingInterceptor.java:813)
> [Server:server-local] at org.infinispan.interceptors.impl.EntryWrappingInterceptor.commitContextEntries(EntryWrappingInterceptor.java:566)
> [Server:server-local] at org.infinispan.interceptors.impl.EntryWrappingInterceptor.applyChanges(EntryWrappingInterceptor.java:617)
> [Server:server-local] at org.infinispan.interceptors.impl.EntryWrappingInterceptor.applyAndFixVersion(EntryWrappingInterceptor.java:678)
> [Server:server-local] at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextThenAccept(BaseAsyncInterceptor.java:105)
> [Server:server-local] at org.infinispan.interceptors.impl.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:672)
> [Server:server-local] at org.infinispan.interceptors.impl.EntryWrappingInterceptor.visitPutKeyValueCommand(EntryWrappingInterceptor.java:302)
> [Server:server-local] at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:68)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months