[JBoss JIRA] (ISPN-11232) Creating resources via REST should allow names compatible with the XML type "xs:ID"
by Gustavo Fernandes (Jira)
[ https://issues.redhat.com/browse/ISPN-11232?page=com.atlassian.jira.plugi... ]
Gustavo Fernandes updated ISPN-11232:
-------------------------------------
Description: Currently it's not possible to create caches/counters/etc containing "/" in the name since it's interpreted as part of the path. Other character may have similar issues (was: Currently it's not possible to create caches/counters/etc containing "/" in the name since it's interpreted by clients are part of the path. Other character may have similar issues)
> Creating resources via REST should allow names compatible with the XML type "xs:ID"
> -----------------------------------------------------------------------------------
>
> Key: ISPN-11232
> URL: https://issues.redhat.com/browse/ISPN-11232
> Project: Infinispan
> Issue Type: Bug
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Major
>
> Currently it's not possible to create caches/counters/etc containing "/" in the name since it's interpreted as part of the path. Other character may have similar issues
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 8 months
[JBoss JIRA] (ISPN-11231) Transcoder lookup is inefficient
by Dan Berindei (Jira)
Dan Berindei created ISPN-11231:
-----------------------------------
Summary: Transcoder lookup is inefficient
Key: ISPN-11231
URL: https://issues.redhat.com/browse/ISPN-11231
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 10.1.1.Final, 9.4.17.Final
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 11.0.0.Alpha1
{{EncoderRegistryImpl}} stores transcoders in a set, without any lookup optimization because it assumes the number of transcoders is small.
However, {{InternalCacheFactory.bootstrap()}} registers a "different" {{TranscoderMarshallerAdapter}} for each cache, even though they all delegate to the same global marshaller.
I believe the global marshaller transcoder adapter should be registered only once in {{EncoderRegistryFactory}}, and ideally we should have a way of looking up transcoders by media types.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 8 months
[JBoss JIRA] (ISPN-11230) Remove all usages of java.util.UUID.randomUUID()
by Dan Berindei (Jira)
Dan Berindei created ISPN-11230:
-----------------------------------
Summary: Remove all usages of java.util.UUID.randomUUID()
Key: ISPN-11230
URL: https://issues.redhat.com/browse/ISPN-11230
Project: Infinispan
Issue Type: Enhancement
Components: CLI, Core, Embedded Querying, Server
Affects Versions: 10.1.1.Final, 9.4.17.Final
Reporter: Dan Berindei
Fix For: 11.0.0.Final
{{java.util.UUID.randomUUID()}} uses a "cryptographically strong pseudo random number generator", which reads from {{/dev/urandom}} (or even {{/dev/random}} in older Java versions), and then computes an expensive cryptographic digest on the bytes it read.
We don't need a cryptographically strong random number, so we can use {{org.infinispan.commons.util.Util.threadLocalRandomUUID()}} instead.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 8 months
[JBoss JIRA] (ISPN-11230) Remove all usages of java.util.UUID.randomUUID()
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-11230?page=com.atlassian.jira.plugi... ]
Dan Berindei reassigned ISPN-11230:
-----------------------------------
Assignee: Dan Berindei
> Remove all usages of java.util.UUID.randomUUID()
> ------------------------------------------------
>
> Key: ISPN-11230
> URL: https://issues.redhat.com/browse/ISPN-11230
> Project: Infinispan
> Issue Type: Enhancement
> Components: CLI, Core, Embedded Querying, Server
> Affects Versions: 9.4.17.Final, 10.1.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 11.0.0.Final
>
>
> {{java.util.UUID.randomUUID()}} uses a "cryptographically strong pseudo random number generator", which reads from {{/dev/urandom}} (or even {{/dev/random}} in older Java versions), and then computes an expensive cryptographic digest on the bytes it read.
> We don't need a cryptographically strong random number, so we can use {{org.infinispan.commons.util.Util.threadLocalRandomUUID()}} instead.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 8 months
[JBoss JIRA] (ISPN-11230) Remove all usages of java.util.UUID.randomUUID()
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-11230?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-11230:
--------------------------------
Status: Open (was: New)
> Remove all usages of java.util.UUID.randomUUID()
> ------------------------------------------------
>
> Key: ISPN-11230
> URL: https://issues.redhat.com/browse/ISPN-11230
> Project: Infinispan
> Issue Type: Enhancement
> Components: CLI, Core, Embedded Querying, Server
> Affects Versions: 9.4.17.Final, 10.1.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 11.0.0.Final
>
>
> {{java.util.UUID.randomUUID()}} uses a "cryptographically strong pseudo random number generator", which reads from {{/dev/urandom}} (or even {{/dev/random}} in older Java versions), and then computes an expensive cryptographic digest on the bytes it read.
> We don't need a cryptographically strong random number, so we can use {{org.infinispan.commons.util.Util.threadLocalRandomUUID()}} instead.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 8 months
[JBoss JIRA] (IPROTO-129) ProtobufUtil.fromWrappedByteArray should not create a ByteArrayInputStream
by Nistor Adrian (Jira)
[ https://issues.redhat.com/browse/IPROTO-129?page=com.atlassian.jira.plugi... ]
Nistor Adrian updated IPROTO-129:
---------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
merged in master and 4.2.x
> ProtobufUtil.fromWrappedByteArray should not create a ByteArrayInputStream
> --------------------------------------------------------------------------
>
> Key: IPROTO-129
> URL: https://issues.redhat.com/browse/IPROTO-129
> Project: Infinispan ProtoStream
> Issue Type: Bug
> Affects Versions: 4.2.5.Final, 4.3.2.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 4.2.6.Final, 4.3.3.Final
>
>
> {{ProtobufUtil.fromWrappedByteArray}} wraps the {{bytep[]}} in a {{ByteArrayInputStream}} and uses that as an input for {{CodedInputStream}}. But that is inefficient, because {{CodedInputStream.StreamDecoder}} needs to allocate a buffer and copy from the stream into the buffer before processing.
> Instead we can pass the {{byte[]}} directly to {{CodedInputStream}} and use {{CodedInputStream.ArrayDecoder}}, which doesn't need a buffer.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 8 months
[JBoss JIRA] (IPROTO-130) Inefficient ProtobufUtil.fromWrappedByteArray(ImmutableSerializationContext ctx, byte[] bytes)
by Nistor Adrian (Jira)
[ https://issues.redhat.com/browse/IPROTO-130?page=com.atlassian.jira.plugi... ]
Nistor Adrian closed IPROTO-130.
--------------------------------
Resolution: Duplicate Issue
> Inefficient ProtobufUtil.fromWrappedByteArray(ImmutableSerializationContext ctx, byte[] bytes)
> -----------------------------------------------------------------------------------------------
>
> Key: IPROTO-130
> URL: https://issues.redhat.com/browse/IPROTO-130
> Project: Infinispan ProtoStream
> Issue Type: Bug
> Affects Versions: 4.2.5.Final, 4.3.2.Final
> Reporter: Nistor Adrian
> Assignee: Nistor Adrian
> Priority: Major
> Fix For: 4.2.6.Final, 4.3.3.Final
>
>
> The implementation uses a ByteArrayInputStream that wraps the byte[], and then creates a CodedInputStream around it and this copies the input data to its own buffer. This should have been made more efficiently by building a CodedInputStream directly around the byte[] (which internally uses CodedInputStream.ArrayDecoder and doesn't need a buffer copy).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 8 months