January 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1994) TCP: remove send queues

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1994?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1994. ---------------------------- Resolution: Done > TCP: remove send queues > ----------------------- > > Key: JGRP-1994 > URL: https://issues.jboss.org/browse/JGRP-1994 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > When {{TCP.use_send_queues}} is enabled, sending a message puts it in a queue from which a sender thread dequeues it and sends it. > This was a bad idea from the start, because > * We create 1 additional (sender) thread per peer. That's 999 threads *per member* if we have a cluster of 1000. Besides, more threads leads to increased context switching > * The queue only tapers over blocking on a TCP write, as it will fill up if the TCP write blocks. So the problem of a bloking write is only moved to a different part of the system, not eliminated. > * We have to *make a copy of every buffer* to be sent as buffers are reused -> unneeded memory allocation -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1225) Remove BasicConnectionTable

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1225?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1225. ---------------------------- Resolution: Done > Remove BasicConnectionTable > --------------------------- > > Key: JGRP-1225 > URL: https://issues.jboss.org/browse/JGRP-1225 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Currently still used by TCP_NIO (ConnectionTableNIO). When we move to NIO2, we can drop this class, as it will be obsolete -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1685) Remove UNICAST(1, 2), NAKACK protocols

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1685?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1685. ---------------------------- Resolution: Done Did *not* rename UNICAST3 to UNICAST etc, to avoid confusion > Remove UNICAST(1,2), NAKACK protocols > ------------------------------------- > > Key: JGRP-1685 > URL: https://issues.jboss.org/browse/JGRP-1685 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Remove older versions of some protocols, e.g. > * Remove UNICAST and UNICAST2, and rename UNICAST3 --> UNICAST > * Remove NAKACK and rename NAKACK2 --> NAKACK > * Remove MERGE and rename MERGE2 --> MERGE > What about RELAY2, Timescheduler2, FRAG2 ? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1937) Configuration: revert order of protocols in configuration

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1937?page=com.atlassian.jira.plugin.... ] Bela Ban closed JGRP-1937. -------------------------- Resolution: Won't Do Big resistance from the wildfly folks > Configuration: revert order of protocols in configuration > --------------------------------------------------------- > > Key: JGRP-1937 > URL: https://issues.jboss.org/browse/JGRP-1937 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Currently, a JGroups configuration lists the protocols in *bottom to top* order, e.g. > {noformat} > <UDP/> > <PING/> > ... > <FRAG2/> > {noformat} > This is somewhat misleading as {{UDP}} is not the top protocol in the resulting stack, but the bottom protocol stack: > {noformat} > FRAG2 > | > PING > | > ... > UDP > {noformat} > Therefore, it would be better to define the configuration as follows: > {noformat} > <FRAG2/> > ... > <PING/> > <UDP/> > {noformat} > To prevent reuse of older configurations in 4.0, we could replace {{<config>}} with {{<jgroups>}}. > A configuration starting with {{<config>}} would be parsed in the old style (plus a warning would be issued) and a config starting with {{<jgroups>}} would be parsed in the new style. > If programmatic configuration is used, we could check which protocol is at the head of the list. If it is a transport protocol ({{UDP}} or {{TCP}}), we could dynamically revert the order and issue a warning. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6049) Modules should be marked private / unsupported

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6049?page=com.atlassian.jira.plugin.... ] Tomaz Cerar moved JBEAP-2974 to WFLY-6049: ------------------------------------------ Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-6049 (was: JBEAP-2974) Issue Type: Task (was: Bug) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Web (Undertow) (was: Web (Undertow)) (was: Modules) Target Release: (was: 7.0.0.GA) Affects Version/s: (was: 7.0.0.ER4) > Modules should be marked private / unsupported > ---------------------------------------------- > > Key: WFLY-6049 > URL: https://issues.jboss.org/browse/WFLY-6049 > Project: WildFly > Issue Type: Task > Components: Web (Undertow) > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Priority: Blocker > Labels: release_notes > > I believe we don't want to support this module yet since server side javascript is going to be technical preview. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6049) Modules should be marked private / unsupported

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6049?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-6049: ------------------------------ Description: Mark modules as folows: io.undertow.js unsupported com.github.spullara.mustache private was:I believe we don't want to support this module yet since server side javascript is going to be technical preview. > Modules should be marked private / unsupported > ---------------------------------------------- > > Key: WFLY-6049 > URL: https://issues.jboss.org/browse/WFLY-6049 > Project: WildFly > Issue Type: Task > Components: Web (Undertow) > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Priority: Blocker > Labels: release_notes > > Mark modules as folows: > io.undertow.js unsupported > com.github.spullara.mustache private -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1321) io.undertow.core module should be private

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1321?page=com.atlassian.jira.plugi... ] Tomaz Cerar moved JBEAP-2973 to WFCORE-1321: -------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-1321 (was: JBEAP-2973) Issue Type: Task (was: Bug) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Modules (was: Web (Undertow)) (was: Modules) Target Release: (was: 7.0.0.GA) Affects Version/s: 2.0.7.Final (was: 7.0.0.ER4) > io.undertow.core module should be private > ----------------------------------------- > > Key: WFCORE-1321 > URL: https://issues.jboss.org/browse/WFCORE-1321 > Project: WildFly Core > Issue Type: Task > Components: Modules > Affects Versions: 2.0.7.Final > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Priority: Blocker > > According to inputs in [Module Classification doc|https://mojo.redhat.com/docs/DOC-1053168] there seems to be agreement between Eng and QA to change visibility of this module to private. I believe we don't want to support this module. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5822) Clustering performance regression in ejbremote-dist-sync scenario

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/WFLY-5822?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz edited comment on WFLY-5822 at 1/22/16 8:58 AM: -------------------------------------------------------------------- In the clustering meeting yesterday, Rado mentioned that part of the difficulty here is that we are comparing EAP6 source code + JDK 6 to EAP 7 source code + JDK 8, and that there are big changes in heap management in JDK 6 vs JDK 8 (removal of permGen and introduction of metaSpace). So, we did a comparison of EAP 6 vs EAP 7 using the same JVM - JDK 8. Here are the results (on two server nodes instead of four): https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-7x-stre... http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-6x-stres... Using the same JVM, EAP 7 hits 13,000 reqs / sec versus EAP 6 hitting 10,000 reqs / sec. Running the same 2 server test for EAP 6 using JDK 6 only yields marginally better results: http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-6x-stres... was (Author: rachmato): In the clustering meeting yesterday, Rado mentioned that part of the difficulty here is that we are comparing EAP6 source code + JDK 6 to EAP 7 source code + JDK 8, and that there are big changes in heap management in JDK 6 vs JDK 8 (removal of permGen and introduction of metaSpace). So, we did a comparison of EAP 6 vs EAP 7 using the same JVM - JDK 8. Here are the results (on two server nodes instead of four): https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-7x-stre... http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-6x-stres... Using the same JVM, EAP 7 hits 13,000 reqs / sec versus EAP 6 hitting 10,000 reqs / sec. Running the same 2 server test for EAP 6 using JDK 6 only yields marginally better results: > Clustering performance regression in ejbremote-dist-sync scenario > ------------------------------------------------------------------ > > Key: WFLY-5822 > URL: https://issues.jboss.org/browse/WFLY-5822 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Affects Versions: 10.0.0.CR5 > Reporter: Michal Vinkler > Assignee: Richard Achmatowicz > Priority: Critical > > Compared to EAP 6, all SYNC scenarios have the same/better performance except of this one, wonder why? > Compare these results: > stress-ejbremote-dist-sync > 7.0.0.ER2: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-str...] > 6.4.0.GA: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-str...] > --------------------------------------- > Just for comparison: ejbremote REPL_SYNC scenario *performs well* on the other hand: > stress-ejbremote-repl-sync > 7.0.0.ER2: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-str...] > 6.4.0.GA: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-str...] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5822) Clustering performance regression in ejbremote-dist-sync scenario

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/WFLY-5822?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz edited comment on WFLY-5822 at 1/22/16 8:58 AM: -------------------------------------------------------------------- Michal, would it be possible to rerun the original 4 node tests using JDK 8? was (Author: rachmato): Michal, would it be possible to rerun the original 4 node tests using JDK 8? > Clustering performance regression in ejbremote-dist-sync scenario > ------------------------------------------------------------------ > > Key: WFLY-5822 > URL: https://issues.jboss.org/browse/WFLY-5822 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Affects Versions: 10.0.0.CR5 > Reporter: Michal Vinkler > Assignee: Richard Achmatowicz > Priority: Critical > > Compared to EAP 6, all SYNC scenarios have the same/better performance except of this one, wonder why? > Compare these results: > stress-ejbremote-dist-sync > 7.0.0.ER2: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-str...] > 6.4.0.GA: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-str...] > --------------------------------------- > Just for comparison: ejbremote REPL_SYNC scenario *performs well* on the other hand: > stress-ejbremote-repl-sync > 7.0.0.ER2: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-str...] > 6.4.0.GA: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-str...] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5822) Clustering performance regression in ejbremote-dist-sync scenario

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/WFLY-5822?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz edited comment on WFLY-5822 at 1/22/16 8:57 AM: -------------------------------------------------------------------- In the clustering meeting yesterday, Rado mentioned that part of the difficulty here is that we are comparing EAP6 source code + JDK 6 to EAP 7 source code + JDK 8, and that there are big changes in heap management in JDK 6 vs JDK 8 (removal of permGen and introduction of metaSpace). So, we did a comparison of EAP 6 vs EAP 7 using the same JVM - JDK 8. Here are the results (on two server nodes instead of four): https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-7x-stre... http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-6x-stres... Using the same JVM, EAP 7 hits 13,000 reqs / sec versus EAP 6 hitting 10,000 reqs / sec. Running the same 2 server test for EAP 6 using JDK 6 only yields marginally better results: was (Author: rachmato): In the clustering meeting yesterday, Rado mentioned that part of the difficulty here is that we are comparing EAP6 source code + JDK 6 to EAP 7 source code + JDK 8, and that there are big changes in heap management in JDK 6 vs JDK 8 (removal of permGen and introduction of metaSpace). So, we did a comparison of EAP 6 vs EAP 7 using the same JVM - JDK 8. Here are the results (on two server nodes instead of four): https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-7x-stre... http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-6x-stres... Using the same JVM, EAP 7 hits 13,000 reqs / sec versus EAP 6 hitting 10,000 reqs / sec. > Clustering performance regression in ejbremote-dist-sync scenario > ------------------------------------------------------------------ > > Key: WFLY-5822 > URL: https://issues.jboss.org/browse/WFLY-5822 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Affects Versions: 10.0.0.CR5 > Reporter: Michal Vinkler > Assignee: Richard Achmatowicz > Priority: Critical > > Compared to EAP 6, all SYNC scenarios have the same/better performance except of this one, wonder why? > Compare these results: > stress-ejbremote-dist-sync > 7.0.0.ER2: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-str...] > 6.4.0.GA: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-str...] > --------------------------------------- > Just for comparison: ejbremote REPL_SYNC scenario *performs well* on the other hand: > stress-ejbremote-repl-sync > 7.0.0.ER2: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-str...] > 6.4.0.GA: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-str...] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2016