December 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1989) Bundlers: reuse send buffer when transport == sync.

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1989?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1989. ---------------------------- Resolution: Done > Bundlers: reuse send buffer when transport == sync. > --------------------------------------------------- > > Key: JGRP-1989 > URL: https://issues.jboss.org/browse/JGRP-1989 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.7 > > > With the addition of {{TCP_NIO2}}, all bundlers now create new send buffers for every message (or message list). This generates a lot of memory allocations, perhaps it is better to revert this change for *synchronous transports* such as {{UDP}} and {{TCP}}, and still create new buffers for *asynchronous transports* such as {{TCP_NIO2}}. > Synchronous transports guarantee a message has been put on the wire when {{TP.send()}} returns, whereas asynchronous transports may only have completed a partial write (so we cannot reuse the buffer). > The code in the bundler should check for this, and copy if async or not copy if sync. > Whether or not a transport is sync is determined by a new abstract method that needs to be overridden by every transport. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1989) Bundlers: reuse send buffer when transport == sync.

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1989?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1989: -------------------------------- OK, so the continuation of this issue is JGRP-1998, which looks into reusing buffers on the receive side. Preliminary results with JMC and UPerf for 2M messages in a cluster of 4 shows a reduction of allocated memory from *16.51GB* to *10.94*! Performance of UPerf didn't increase though, but apps running on JGroups might benefit from this reduction. > Bundlers: reuse send buffer when transport == sync. > --------------------------------------------------- > > Key: JGRP-1989 > URL: https://issues.jboss.org/browse/JGRP-1989 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.7 > > > With the addition of {{TCP_NIO2}}, all bundlers now create new send buffers for every message (or message list). This generates a lot of memory allocations, perhaps it is better to revert this change for *synchronous transports* such as {{UDP}} and {{TCP}}, and still create new buffers for *asynchronous transports* such as {{TCP_NIO2}}. > Synchronous transports guarantee a message has been put on the wire when {{TP.send()}} returns, whereas asynchronous transports may only have completed a partial write (so we cannot reuse the buffer). > The code in the bundler should check for this, and copy if async or not copy if sync. > Whether or not a transport is sync is determined by a new abstract method that needs to be overridden by every transport. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1998) Transport: reuse of incoming buffers

by Bela Ban (JIRA)

Bela Ban created JGRP-1998: ------------------------------ Summary: Transport: reuse of incoming buffers Key: JGRP-1998 URL: https://issues.jboss.org/browse/JGRP-1998 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.6.7 Investigate whether buffers can be reused on the receive side. JGRP-1989 already provides this on the send side. Goal: reduction of memory allocation rate. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1163) Provide an API to access the main XML element parsers

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1163?page=com.atlassian.jira.plugi... ] Darran Lofthouse commented on WFCORE-1163: ------------------------------------------ If we can get this in quick I can get it merged to my branch and reworked before going on PTO. > Provide an API to access the main XML element parsers > ----------------------------------------------------- > > Key: WFCORE-1163 > URL: https://issues.jboss.org/browse/WFCORE-1163 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Heiko Braun > Assignee: Heiko Braun > Labels: affects_elytron > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1163) Provide an API to access the main XML element parsers

by Heiko Braun (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1163?page=com.atlassian.jira.plugi... ] Heiko Braun commented on WFCORE-1163: ------------------------------------- [~brian.stansberry] I guess we can remove the dependency on [~dlofthouse]'s work? There are some blocking issues declared, but if I understand you correctly the changes related to this issue can be merged independently? > Provide an API to access the main XML element parsers > ----------------------------------------------------- > > Key: WFCORE-1163 > URL: https://issues.jboss.org/browse/WFCORE-1163 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Heiko Braun > Assignee: Heiko Braun > Labels: affects_elytron > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5758) Getting [Management resource '[(\"subsystem\" => \"undertow\")]' not found] when removing ressources from Undertow

by Montpa Pasteur (JIRA)

[ https://issues.jboss.org/browse/WFLY-5758?page=com.atlassian.jira.plugin.... ] Montpa Pasteur commented on WFLY-5758: -------------------------------------- I don't know if this relevant, but when i start my wildfly and run my script to get the list of datasources, i have to wait like a minute to get this list, before that i get an empty list. > Getting [Management resource '[(\"subsystem\" => \"undertow\")]' not found] when removing ressources from Undertow > ------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-5758 > URL: https://issues.jboss.org/browse/WFLY-5758 > Project: WildFly > Issue Type: Bug > Components: CLI > Affects Versions: 8.x.x TBD > Environment: Wildfly 8.2.1 on SUSE Linux 11.1 and Solaris 11 > Reporter: Montpa Pasteur > Assignee: Alexey Loubyansky > Priority: Minor > > When trying remove more that one resource from Undertow using the CLI, I am getting this message: *[Management resource '[(\"subsystem\" => \"undertow\")]' not found*] > This doesn't happen all time, it looks like random. Adding a sleep between the CLI command helps some time. > I get this problem when trying to remove http request header configuration and when trying to remove static ressource serving configuration(location, file handler, filter ..) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1997) Bundler: find new default bundler

by Bela Ban (JIRA)

Bela Ban created JGRP-1997: ------------------------------ Summary: Bundler: find new default bundler Key: JGRP-1997 URL: https://issues.jboss.org/browse/JGRP-1997 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 4.0 Before removing the deprecated sender-sends-with-timer bundler, assess which bundler is the fastest across a range of applications (UPerf, Infinispan etc). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5758) Getting [Management resource '[(\"subsystem\" => \"undertow\")]' not found] when removing ressources from Undertow

by Montpa Pasteur (JIRA)

[ https://issues.jboss.org/browse/WFLY-5758?page=com.atlassian.jira.plugin.... ] Montpa Pasteur commented on WFLY-5758: -------------------------------------- No, I am using a python script that call jboss-cli.sh with the paramters. Each command executed is basically a call to jboss-cli.sh with the name of a file containing the command to execute. The use of a sleep between commands seems to help sometimes but .. sometimes not. My python script calls the commands sequentially. I am having this problem when I try to remove more than one part of the config, right now i am having the problem when i try to remove RBAC authentification ressources. It looks like wildfly have some problem refreshing its config. I don't know if this is relevant but the execution of these commands is really slow. I tried the same command set on my Windows machine but i can't reproduce the problem. > Getting [Management resource '[(\"subsystem\" => \"undertow\")]' not found] when removing ressources from Undertow > ------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-5758 > URL: https://issues.jboss.org/browse/WFLY-5758 > Project: WildFly > Issue Type: Bug > Components: CLI > Affects Versions: 8.x.x TBD > Environment: Wildfly 8.2.1 on SUSE Linux 11.1 and Solaris 11 > Reporter: Montpa Pasteur > Assignee: Alexey Loubyansky > Priority: Minor > > When trying remove more that one resource from Undertow using the CLI, I am getting this message: *[Management resource '[(\"subsystem\" => \"undertow\")]' not found*] > This doesn't happen all time, it looks like random. Adding a sleep between the CLI command helps some time. > I get this problem when trying to remove http request header configuration and when trying to remove static ressource serving configuration(location, file handler, filter ..) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1232) Adjust patching tests to use merged patches

by Jan Martiska (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1232?page=com.atlassian.jira.plugi... ] Jan Martiska moved JBEAP-2430 to WFCORE-1232: --------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-1232 (was: JBEAP-2430) Workflow: GIT Pull Request workflow (was: CDW v1) Component/s: Patching Test Suite (was: Patching) (was: Test Suite) Target Release: (was: 7.0.0.GA) Affects Version/s: 2.0.4.Final (was: 7.0.0.ER3) > Adjust patching tests to use merged patches > ------------------------------------------- > > Key: WFCORE-1232 > URL: https://issues.jboss.org/browse/WFCORE-1232 > Project: WildFly Core > Issue Type: Bug > Components: Patching , Test Suite > Affects Versions: 2.0.4.Final > Reporter: Jan Martiska > Assignee: Jan Martiska > > WFCORE-838 introduced a new way of joining multiple patches together - merging them into one. This needs some test coverage in patching TS. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1231) Remove OSGi bundle related patching tests

by Jan Martiska (JIRA)

Jan Martiska created WFCORE-1231: ------------------------------------ Summary: Remove OSGi bundle related patching tests Key: WFCORE-1231 URL: https://issues.jboss.org/browse/WFCORE-1231 Project: WildFly Core Issue Type: Bug Components: Patching , Test Suite Affects Versions: 2.0.4.Final Reporter: Jan Martiska Assignee: Jan Martiska Priority: Minor OSGi is no longer supported, there's no point in keeping these tests. This affects unit tests in the 'patching' module and the patching module of integration TS. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 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 December 2015