July 2018 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-8756) Implement Single Port

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-8756?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec updated ISPN-8756: -------------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/5728, https://github.com/infinispan/infinispan/pull/6133 (was: https://github.com/infinispan/infinispan/pull/5728) > Implement Single Port > --------------------- > > Key: ISPN-8756 > URL: https://issues.jboss.org/browse/ISPN-8756 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > > Design document: https://github.com/infinispan/infinispan-designs/blob/master/Single_port.... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9352) Report cache read/write/remote stats also as nanoseconds

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-9352?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9352: ---------------------------------- Status: Open (was: New) > Report cache read/write/remote stats also as nanoseconds > -------------------------------------------------------- > > Key: ISPN-9352 > URL: https://issues.jboss.org/browse/ISPN-9352 > Project: Infinispan > Issue Type: Enhancement > Components: JMX, reporting and management > Affects Versions: 9.3.0.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.4.0.Alpha1, 9.4.0.Final > > > Add three new stats that report read/write/remove averages in nanoseconds. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9352) Report cache read/write/remote stats also as nanoseconds

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-9352?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9352: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/6132 > Report cache read/write/remote stats also as nanoseconds > -------------------------------------------------------- > > Key: ISPN-9352 > URL: https://issues.jboss.org/browse/ISPN-9352 > Project: Infinispan > Issue Type: Enhancement > Components: JMX, reporting and management > Affects Versions: 9.3.0.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.4.0.Alpha1, 9.4.0.Final > > > Add three new stats that report read/write/remove averages in nanoseconds. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9345) TimeutException involving the org.infinispan.CONFIG cache

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/ISPN-9345?page=com.atlassian.jira.plugin.... ] Bela Ban commented on ISPN-9345: -------------------------------- OK, thanks for the update! All protocol headers have small (fixed) sizes and the headers added to a message below FRAG3 are typically retransmission (NAKACK2 or UNICAST3) and transport (UDP or TCP), so reducing max_bundle_size by this offset should work in most cases. For TCP, max_bundle_size could be quite large, but I guess this also increases the burden on memory as message are collected until they're sent. If you use {{no-bundler}}, then max_bundle_size is moot, anyway. > TimeutException involving the org.infinispan.CONFIG cache > --------------------------------------------------------- > > Key: ISPN-9345 > URL: https://issues.jboss.org/browse/ISPN-9345 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.3.0.Final > Reporter: Gustavo Fernandes > Assignee: Dan Berindei > > {noformat} > Caused by: org.infinispan.commons.CacheException: Initial state transfer timed out for cache org.infinispan.CONFIG on jedha-64980 > at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:233) > 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:498) > at org.infinispan.commons.util.SecurityActions.lambda$invokeAccessibly$0(SecurityActions.java:79) > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9345) TimeutException involving the org.infinispan.CONFIG cache

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-9345?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-9345: ------------------------------------ [~belaban] after reading some more about IPv6 I realized I jumped to conclusions: the do-not-fragment rule is only for routers, and the network stack on the sender is free to fragment the packets: {quote} In order to send a packet that is too large to fit in the MTU of the path to its destination, a source node may divide the packet into fragments and send each fragment as a separate packet, to be reassembled at the receiver. {quote} These logs from `tcpdump` actually show that a packet was fragmented, and the "bad length" message is logged by tcpdump every time the UDP datagram size is bigger than the IP packet size: {noformat} 09:30:32.070507 IP6 (class 0x08, flowlabel 0xbb8fe, hlim 2, next-header Fragment (44) payload length: 1456) denulu-tp3 > ff0e::e406:708: frag (0xbbd85d01:0|1448) 56784 > 46655: UDP, bad length 1453 > 1440 09:30:32.070563 IP6 (class 0x08, flowlabel 0xbb8fe, hlim 2, next-header Fragment (44) payload length: 21) denulu-tp3 > ff0e::e406:708: frag (0xbbd85d01:1448|13) {noformat} This is a non-fragmented packet, with the length just below the threshold: {noformat} 09:31:21.935633 IP6 (class 0x08, flowlabel 0x839b7, hlim 2, next-header UDP (17) payload length: 1460) denulu-tp3.57807 > ff0e::e406:708.46655: [udp sum ok] UDP, length 1452 {noformat} Initially I thought it was a problem with the wireless router I was connected to at the time. But I was able to reproduce the problem by connecting only to an ethernet switch, so I'm now convinced the problem is in my machine's IPv6 stack. {quote} Sending a large packet at startup is too cumbersome, but this could be integrated into some configuration task perhaps? {quote} Well, it wouldn't be a simple configuration change, but we can surely modify {{FRAGx}} to send a message with {{frag_size}} bytes on startup/view change and log an error if there is no confirmation from the coordinator? I'm not sure what to do with all the protocols below {{FRAGx}} that send data in the message body. Maybe they can check {{TP.max_bundle_size}} and do their own fragmentation based on that? The only inconvenience would be that {{TP.max_bundle_size}} is always set, even when using {{TCP}}, and we wouldn't need fragmentation there. > TimeutException involving the org.infinispan.CONFIG cache > --------------------------------------------------------- > > Key: ISPN-9345 > URL: https://issues.jboss.org/browse/ISPN-9345 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.3.0.Final > Reporter: Gustavo Fernandes > Assignee: Dan Berindei > > {noformat} > Caused by: org.infinispan.commons.CacheException: Initial state transfer timed out for cache org.infinispan.CONFIG on jedha-64980 > at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:233) > 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:498) > at org.infinispan.commons.util.SecurityActions.lambda$invokeAccessibly$0(SecurityActions.java:79) > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9352) Report cache read/write/remote stats also as nanoseconds

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-9352: ------------------------------------- Summary: Report cache read/write/remote stats also as nanoseconds Key: ISPN-9352 URL: https://issues.jboss.org/browse/ISPN-9352 Project: Infinispan Issue Type: Enhancement Components: JMX, reporting and management Affects Versions: 9.3.0.Final Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 9.4.0.Alpha1, 9.4.0.Final Add three new stats that report read/write/remove averages in nanoseconds. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9345) TimeutException involving the org.infinispan.CONFIG cache

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-9345?page=com.atlassian.jira.plugin.... ] Dan Berindei reassigned ISPN-9345: ---------------------------------- Assignee: Dan Berindei > TimeutException involving the org.infinispan.CONFIG cache > --------------------------------------------------------- > > Key: ISPN-9345 > URL: https://issues.jboss.org/browse/ISPN-9345 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.3.0.Final > Reporter: Gustavo Fernandes > Assignee: Dan Berindei > > {noformat} > Caused by: org.infinispan.commons.CacheException: Initial state transfer timed out for cache org.infinispan.CONFIG on jedha-64980 > at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:233) > 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:498) > at org.infinispan.commons.util.SecurityActions.lambda$invokeAccessibly$0(SecurityActions.java:79) > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9345) TimeutException involving the org.infinispan.CONFIG cache

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-9345?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-9345: ------------------------------- Status: Open (was: New) > TimeutException involving the org.infinispan.CONFIG cache > --------------------------------------------------------- > > Key: ISPN-9345 > URL: https://issues.jboss.org/browse/ISPN-9345 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.3.0.Final > Reporter: Gustavo Fernandes > Assignee: Dan Berindei > > {noformat} > Caused by: org.infinispan.commons.CacheException: Initial state transfer timed out for cache org.infinispan.CONFIG on jedha-64980 > at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:233) > 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:498) > at org.infinispan.commons.util.SecurityActions.lambda$invokeAccessibly$0(SecurityActions.java:79) > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8905) Segment-aware non-shared cache stores

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8905?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-8905: -------------------------------- Status: Open (was: New) > Segment-aware non-shared cache stores > ------------------------------------- > > Key: ISPN-8905 > URL: https://issues.jboss.org/browse/ISPN-8905 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: William Burns > Assignee: William Burns > Fix For: 9.4.0.Final > > > Non shared stores should allow for segment based store separation. This might involve creating a store per segment. But this allows for superior iteration performance over a subset of segments. > Distributed stores benefit the most from this due to the fact that iteration is done at the segment level to help ensure that duplicate entries are not retrieved. It also would be beneficial for state transfer and other operations that operate only upon a given set of segments. > This could be advantageous even for REPL and LOCAL caches as there is then a very clear separation of stores to process in parallel for given operations. This would have to be verified with tests to see if this is worth it though. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8905) Segment-aware non-shared cache stores

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8905?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-8905: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/6131 > Segment-aware non-shared cache stores > ------------------------------------- > > Key: ISPN-8905 > URL: https://issues.jboss.org/browse/ISPN-8905 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: William Burns > Assignee: William Burns > Fix For: 9.4.0.Final > > > Non shared stores should allow for segment based store separation. This might involve creating a store per segment. But this allows for superior iteration performance over a subset of segments. > Distributed stores benefit the most from this due to the fact that iteration is done at the segment level to help ensure that duplicate entries are not retrieved. It also would be beneficial for state transfer and other operations that operate only upon a given set of segments. > This could be advantageous even for REPL and LOCAL caches as there is then a very clear separation of stores to process in parallel for given operations. This would have to be verified with tests to see if this is worth it though. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2018