[JBoss JIRA] (ISPN-12307) Improve media type parsing
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-12307?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-12307:
--------------------------------
Status: Open (was: New)
> Improve media type parsing
> --------------------------
>
> Key: ISPN-12307
> URL: https://issues.redhat.com/browse/ISPN-12307
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Dan Berindei
> Priority: Major
>
> Media type parsing has some problems with double-quoted parameters:
> * {{;}} and {{,}} are interpreted as parameter/media type separator even when they occur in a quoted parameter value
> * {{'}} is interpreted as a quoting character, the spec says only {{"}} must be used for quoting
> * Only spaces are allowed, not {{\t}}.
> * Spaces are allowed in too many places, e.g. {{type / subtype}} or {{parameter = value}}
> * Start and end quotes are removed from quoted parameter values, but the escaped characters inside are not unescaped.
> * Quotes are not added back in {{toString()}}, which makes deserialization fail if one of the parameters included an escaped double-quote (e.g. {{type/subtype; param="\""}}).
> Performance can also be improved, as we create many {{String}} instances via {{trim()}}, {{substring()}}, or {{split()}}.
> The clearest explanation of the media type grammar seems to be in
> https://tools.ietf.org/html/rfc7231#section-3.1.1.1
> https://tools.ietf.org/html/rfc7230#section-3.2.6
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 6 months
[JBoss JIRA] (ISPN-12335) Expose rebalancing progress
by Dan Berindei (Jira)
Dan Berindei created ISPN-12335:
-----------------------------------
Summary: Expose rebalancing progress
Key: ISPN-12335
URL: https://issues.redhat.com/browse/ISPN-12335
Project: Infinispan
Issue Type: Feature Request
Components: Core
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 12.0.0.Final
Rebalancing sometimes takes a long time without logging anything (except at TRACE level). We need to expose the progress somehow: either the number of transferred segments, the number of transferred entries, or maybe even the size of the transferred entries when the size is available.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 6 months
[JBoss JIRA] (ISPN-6901) ConsistentHashV2IntegrationTest.testCorrectBalancingOfKeysAfterNodeKill fails
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-6901?page=com.atlassian.jira.plugin... ]
Dan Berindei updated ISPN-6901:
-------------------------------
Status: Pull Request Sent (was: Reopened)
Git Pull Request: https://github.com/infinispan/infinispan/pull/8645, https://github.com/infinispan/infinispan/pull/8696 (was: https://github.com/infinispan/infinispan/pull/8645)
> ConsistentHashV2IntegrationTest.testCorrectBalancingOfKeysAfterNodeKill fails
> ------------------------------------------------------------------------------
>
> Key: ISPN-6901
> URL: https://issues.redhat.com/browse/ISPN-6901
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite
> Reporter: Sebastian Laskawiec
> Assignee: Dan Berindei
> Priority: Critical
> Labels: testsuite_stability
>
> http://ci.infinispan.org/viewLog.html?buildId=41261&tab=buildResultsDiv&b...
> {code}
> java.lang.AssertionError: expected:<ConsistentHashV2IntegrationTest-NodeA-19908> but was:<ConsistentHashV2IntegrationTest-NodeC-27627>
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
> at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:88)
> at org.infinispan.client.hotrod.ConsistentHashV2IntegrationTest.runTest(ConsistentHashV2IntegrationTest.java:123)
> at org.infinispan.client.hotrod.ConsistentHashV2IntegrationTest.testCorrectBalancingOfKeysAfterNodeKill(ConsistentHashV2IntegrationTest.java:178)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:348)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:38)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> ------- Stdout: -------
> [TestSuiteProgress] Test failed: org.infinispan.client.hotrod.ConsistentHashV2IntegrationTest.testCorrectBalancingOfKeysAfterNodeKill
> 16:32:18,038 ERROR (testng-ConsistentHashV2IntegrationTest) [TestSuiteProgress] Test failed: org.infinispan.client.hotrod.ConsistentHashV2IntegrationTest.testCorrectBalancingOfKeysAfterNodeKill
> java.lang.AssertionError: expected:<ConsistentHashV2IntegrationTest-NodeA-19908> but was:<ConsistentHashV2IntegrationTest-NodeC-27627>
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
> at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:88)
> at org.infinispan.client.hotrod.ConsistentHashV2IntegrationTest.runTest(ConsistentHashV2IntegrationTest.java:123)
> at org.infinispan.client.hotrod.ConsistentHashV2IntegrationTest.testCorrectBalancingOfKeysAfterNodeKill(ConsistentHashV2IntegrationTest.java:178)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[TestSuiteProgress] Tests succeeded: 1485, failed: 1, skipped: 0
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 6 months
[JBoss JIRA] (IPROTO-155) FileDescriptors use too much memory
by Nistor Adrian (Jira)
[ https://issues.redhat.com/browse/IPROTO-155?page=com.atlassian.jira.plugi... ]
Nistor Adrian commented on IPROTO-155:
--------------------------------------
omg, what a mess! I'll try to clean that up in 4.3 also, but 4.4 rewrites that almost completely. and the mess might be even bigger in 4.4 :)
> FileDescriptors use too much memory
> -----------------------------------
>
> Key: IPROTO-155
> URL: https://issues.redhat.com/browse/IPROTO-155
> Project: Infinispan ProtoStream
> Issue Type: Bug
> Affects Versions: 4.3.3.Final
> Reporter: Dan Berindei
> Assignee: Nistor Adrian
> Priority: Minor
>
> E.g. a single {{persistence.counters.proto}} {{FileDescriptor}} instance uses 967KB.
> I'm not sure if the field documentation is useful for anything after the annotations have been parsed, but it is kept in memory, and in a hotrod-client test each {{DefaultCacheManager}} instance seem to need 3 instances of the string {{There is no native byte type in protobuf so it is mapped to int32.}} from the {{WrappedMessage.wrappedByte}} documentation.
> Many lists are {{LinkedList}} instances, even though a {{LinkedList}} with 3 elements uses more memory than an {{ArrayList}} with 10 elements. Some lists are also wrapped in {{Collections$UnmodifiableRandomAccessList}} twice.
> {{FileDescriptor}} {{HashMap}} fields ({{extendDescriptors}}, {{dependants}}) are never queried by key.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 6 months
[JBoss JIRA] (IPROTO-155) FileDescriptors use too much memory
by Nistor Adrian (Jira)
[ https://issues.redhat.com/browse/IPROTO-155?page=com.atlassian.jira.plugi... ]
Nistor Adrian reassigned IPROTO-155:
------------------------------------
Assignee: Nistor Adrian
> FileDescriptors use too much memory
> -----------------------------------
>
> Key: IPROTO-155
> URL: https://issues.redhat.com/browse/IPROTO-155
> Project: Infinispan ProtoStream
> Issue Type: Bug
> Affects Versions: 4.3.3.Final
> Reporter: Dan Berindei
> Assignee: Nistor Adrian
> Priority: Minor
>
> E.g. a single {{persistence.counters.proto}} {{FileDescriptor}} instance uses 967KB.
> I'm not sure if the field documentation is useful for anything after the annotations have been parsed, but it is kept in memory, and in a hotrod-client test each {{DefaultCacheManager}} instance seem to need 3 instances of the string {{There is no native byte type in protobuf so it is mapped to int32.}} from the {{WrappedMessage.wrappedByte}} documentation.
> Many lists are {{LinkedList}} instances, even though a {{LinkedList}} with 3 elements uses more memory than an {{ArrayList}} with 10 elements. Some lists are also wrapped in {{Collections$UnmodifiableRandomAccessList}} twice.
> {{FileDescriptor}} {{HashMap}} fields ({{extendDescriptors}}, {{dependants}}) are never queried by key.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 6 months
[JBoss JIRA] (IPROTO-155) FileDescriptors use too much memory
by Nistor Adrian (Jira)
[ https://issues.redhat.com/browse/IPROTO-155?page=com.atlassian.jira.plugi... ]
Nistor Adrian updated IPROTO-155:
---------------------------------
Status: Open (was: New)
> FileDescriptors use too much memory
> -----------------------------------
>
> Key: IPROTO-155
> URL: https://issues.redhat.com/browse/IPROTO-155
> Project: Infinispan ProtoStream
> Issue Type: Bug
> Affects Versions: 4.3.3.Final
> Reporter: Dan Berindei
> Assignee: Nistor Adrian
> Priority: Minor
>
> E.g. a single {{persistence.counters.proto}} {{FileDescriptor}} instance uses 967KB.
> I'm not sure if the field documentation is useful for anything after the annotations have been parsed, but it is kept in memory, and in a hotrod-client test each {{DefaultCacheManager}} instance seem to need 3 instances of the string {{There is no native byte type in protobuf so it is mapped to int32.}} from the {{WrappedMessage.wrappedByte}} documentation.
> Many lists are {{LinkedList}} instances, even though a {{LinkedList}} with 3 elements uses more memory than an {{ArrayList}} with 10 elements. Some lists are also wrapped in {{Collections$UnmodifiableRandomAccessList}} twice.
> {{FileDescriptor}} {{HashMap}} fields ({{extendDescriptors}}, {{dependants}}) are never queried by key.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 6 months
[JBoss JIRA] (ISPN-12309) Creating cache with invalid configuration leaves inconsistent state
by Gustavo Fernandes (Jira)
[ https://issues.redhat.com/browse/ISPN-12309?page=com.atlassian.jira.plugi... ]
Gustavo Fernandes reassigned ISPN-12309:
----------------------------------------
Assignee: Gustavo Fernandes
> Creating cache with invalid configuration leaves inconsistent state
> -------------------------------------------------------------------
>
> Key: ISPN-12309
> URL: https://issues.redhat.com/browse/ISPN-12309
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Reporter: Katia Aresti
> Assignee: Gustavo Fernandes
> Priority: Critical
>
> When a cache is created using the EmbeddedCacheManagerAdmin with a configuration that prevents the cache from starting, it will throw an error but will persist the cache nonetheless.
> Further operations involving cache manager can throw exceptions, for example, {{Health.getHealth()}} since it tries to access the invalid cache that cannot be started
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 6 months