[JBoss JIRA] (ISPN-11049) Infinispan Server should resolve all the console URLs
by Pedro Zapata Fernandez (Jira)
[ https://issues.redhat.com/browse/ISPN-11049?page=com.atlassian.jira.plugi... ]
Pedro Zapata Fernandez updated ISPN-11049:
------------------------------------------
Sprint: DataGrid Sprint #37, DataGrid Sprint #38 (was: DataGrid Sprint #37)
> Infinispan Server should resolve all the console URLs
> -----------------------------------------------------
>
> Key: ISPN-11049
> URL: https://issues.redhat.com/browse/ISPN-11049
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 10.1.0.Beta1
> Reporter: Katia Aresti
> Assignee: Katia Aresti
> Priority: Major
>
> Infinispan server serves the console from the static resources. This console is an front end app built in react that contains multiple URL paths.
> When we do F5 on a URL that is not 'console' or 'console/wlecome' the server responds with 404.
> The static resource (or console resource) should be able to serve the console app from any of the '/console/*' Urls so there is no 404 when there ir s refresh
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (ISPN-11035) XSiteResourceTest.testPushAllCaches random failures
by Pedro Zapata Fernandez (Jira)
[ https://issues.redhat.com/browse/ISPN-11035?page=com.atlassian.jira.plugi... ]
Pedro Zapata Fernandez updated ISPN-11035:
------------------------------------------
Sprint: DataGrid Sprint #37, DataGrid Sprint #38 (was: DataGrid Sprint #37)
> XSiteResourceTest.testPushAllCaches random failures
> ---------------------------------------------------
>
> Key: ISPN-11035
> URL: https://issues.redhat.com/browse/ISPN-11035
> Project: Infinispan
> Issue Type: Bug
> Components: Cross-Site Replication, REST, Test Suite
> Affects Versions: 10.1.0.Beta1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 10.1.0.CR1
>
>
> The test doesn't seem to wait enough for the xsite state transfer to finish. When it fails, there is only one request to `/rest/v2/cache-managers/default/x-site/backups`, before the remote site receives the state:
> {noformat}
> 19:32:35,797 TRACE (REST-Test-Test-NodeA-48205-ServerIO-15-9:[]) [REST_ACCESS_LOG] /rest/v2/cache-managers/default/x-site/backups
> 19:32:35,807 TRACE (jgroups-4,bridge-org.infinispan.rest.resources.Test,_Test-NodeC-47561:SFO-3:[]) [JGroupsTransport] Test-NodeC-47561 received request 628 from Test-NodeA-48205:LON-1: XSiteStatePushCommand{cacheName=CACHE_2, timeout=1200000 (10 keys)}
> 19:32:35,809 TRACE (REST-Test-Test-NodeC-47561-ServerIO-21-1:[]) [InvocationContextInterceptor] Invoked with command SizeCommand{} and InvocationContext [org.infinispan.context.impl.NonTxInvocationContext@30b93450]
> 19:32:35,813 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.rest.resources.XSiteResourceTest.testPushAllCaches
> java.lang.AssertionError: expected:<10> but was:<9>
> 19:32:35,813 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.rest.resources.XSiteResourceTest.testPushAllCaches
> java.lang.AssertionError: expected:<10> but was:<9>
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.14.3.jar:?]
> at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364) ~[testng-6.14.3.jar:?]
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80) ~[testng-6.14.3.jar:?]
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:245) ~[testng-6.14.3.jar:?]
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:252) ~[testng-6.14.3.jar:?]
> at org.infinispan.rest.resources.XSiteResourceTest.testPushAllCaches(XSiteResourceTest.java:330) ~[test-classes/:?]
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (ISPN-11005) HotRod decoder small performance improvements
by Pedro Zapata Fernandez (Jira)
[ https://issues.redhat.com/browse/ISPN-11005?page=com.atlassian.jira.plugi... ]
Pedro Zapata Fernandez updated ISPN-11005:
------------------------------------------
Sprint: DataGrid Sprint #37, DataGrid Sprint #38 (was: DataGrid Sprint #37)
> HotRod decoder small performance improvements
> ---------------------------------------------
>
> Key: ISPN-11005
> URL: https://issues.redhat.com/browse/ISPN-11005
> Project: Infinispan
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 10.1.0.Beta1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Minor
> Labels: performace
> Fix For: 10.1.0.Final
>
>
> I noticed some small inefficiencies in the flight recordings from the client-server dist read benchmarks:
> * {{Intrinsics.string()}} allocates a temporary {{byte[]}}, we could use {{ByteBuf.toString(start, length, Charset)}} instead (which reuses a thread-local buffer).
> * For reading the cache name it would be even better to use {{ByteString}} and avoid the UTF8 decoding.
> * {{MediaType.hashCode()}} allocates an iterator for the params map even though it's empty.
> * {{JBossMarshallingTranscoder.transcode()}} is called twice for each requests, and even when there is no transcoding to perform it does a lot of {{String.equals()}} checks.
> * {{CacheImpl.getCacheEntryAsync()}} allocates a new {{CompletableFuture}} via {{applyThen()}} just to change the return type, could do the same thing by casting to the erased type.
> * {{EncoderCache.getCacheEntryAsync()}} could also avoid allocating a {{CompletableFuture}} when the read was synchronous.
> * {{Encoder2x}} is stateless, and yet a new instance is created for each request.
> * {{Encoder2x.writeHeader()}} looks up the cache info a second time, as most requests needed that info to execute the operation, plus one useless (I think) {{String.equals()}} check for the counter cache.
> There are also a few issues with the benchmark itself:
> * The load stage took less than 3 mins according to the logs, but flight recordings show {{PutKeyValueCommand}}s being executed at least 1 minute after the end of the load phase.
> * Either RadarGun or FlightRecorder itself is doing lots of JMX calls that throw exceptions constantly through the benchmark, allocating lots of {{StackTraceElement}} instances.
> * Finally, the cluster is unstable, and some nodes are excluded even though the network seems to be fine and GC pauses are quite small.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months