January 2016 - jboss-jira - Jboss List Archives

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

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/JGRP-1989?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on JGRP-1989: ------------------------------------ [~sannegrinovero], I was just replying to your assertion that 16 bytes is a negligible overhead compared to the buffer size. That's definitely not true in your example of 2-15 byte values, where a {{Buffer}} instance to keep track of off-heap memory is going to be just as big as the original {{byte[]}}. > 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)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1985) Message: make initial size of headers configurable

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1985?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1985: -------------------------------- OK, makes sense > Message: make initial size of headers configurable > -------------------------------------------------- > > Key: JGRP-1985 > URL: https://issues.jboss.org/browse/JGRP-1985 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.7 > > > By default a message creates a {{Headers}} instance of 3. This is usually enough (transport, either {{NAKACK2}} or {{UNICAST3}}, and possibly fragmentation). However, if a message needs 4 or more headers, there's a resize which is an additional copy of 2 small arrays. > Goal: make the initial headers size configurable. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5922) Cannot exclude java.orb.api module

by John Farrelly (JIRA)

[ https://issues.jboss.org/browse/WFLY-5922?page=com.atlassian.jira.plugin.... ] John Farrelly commented on WFLY-5922: ------------------------------------- After applying the changes in your PR to my local wildfly installation, I also had to add {{javax.transaction.api}} as a dependency to {{org.jboss.ejb-client}} to get the dependencies to resolve: {code:diff} diff --git a/feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb-client/main/module.xml b/feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb-client/main/module.xml index dca715f..086f12b 100644 --- a/feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb-client/main/module.xml +++ b/feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb-client/main/module.xml @@ -29,6 +29,7 @@ <dependencies> <module name="javax.api"/> <module name="javax.ejb.api"/> + <module name="javax.transaction.api"/> <module name="javax.interceptor.api"/> <module name="org.jboss.remoting"/> <module name="org.jboss.jboss-transaction-spi"/> {code} > Cannot exclude java.orb.api module > ---------------------------------- > > Key: WFLY-5922 > URL: https://issues.jboss.org/browse/WFLY-5922 > Project: WildFly > Issue Type: Bug > Components: Class Loading > Affects Versions: 10.0.0.CR4 > Environment: Red Hat Enterprise Linux Server release 7.1 (Maipo) > Linux 3.10.0-229.4.2.el7.x86_64 #1 SMP Wed May 13 10:06:09 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > java version "1.8.0_60" > Java(TM) SE Runtime Environment (build 1.8.0_60-b27) > Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode) > Reporter: John Farrelly > Assignee: David Lloyd > Priority: Blocker > > We use Orbacus as our CORBA implementation, and in our application we wish to use CORBA classes only from the orbacus module, and not the JDK/WildFly bundled CORBA. > In the {{jboss-deployment-structure.xml}} file of our {{ear}} file, we have the following: > {code:xml} > <?xml version="1.0" encoding="UTF-8"?> > <jboss-deployment-structure> > <ear-subdeployments-isolated>false</ear-subdeployments-isolated> > <deployment> > <exclusions> > <module name="javax.orb.api" /> > <module name="org.omg.api" /> > </exclusions> > <dependencies> > <module name="com.ooc.orbacus" export="true"/> > <module name="org.apache.commons.logging" export="true" /> > <module name="org.apache.commons.collections" export="true" /> > <module name="org.apache.log4j" export="true" /> > <module name="org.dom4j" export="true" /> > <module name="org.jdom" export="true" /> > <module name="javax.faces.api" slot="mojarra-2.1.23" export="true"/> > <module name="com.sun.jsf-impl" slot="mojarra-2.1.23" export="true"/> > <module name="org.jboss.ejb-client" export="true" /> > <module name="org.jboss.remote-naming" export="true" /> > <module name="org.jboss.remoting3" export="true" /> > <module name="org.apache.xerces" /> >  > <module name="com.google.guava" slot="11.0.2" export="true"/> > </dependencies> > </deployment> > ... > {code} > However, despite excluding the {{javax.orb.api}} module, I can see that {{org.omg.PortableServer.Servant}} is loaded from that module instead of being loaded from our {{com.ooc.orbacus}} module. This causes our application to fail. > Debugging through the jboss module loader, I can see that it considers both {{javax.orb.api}} and {{com.ooc.orbacus}} as prodivers of the {{org/omg/PortableServer}} path. I am not sure why {{javax.orb.api}} is being considered when it has been excluded in the deployment descriptor for the application. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1985) Message: make initial size of headers configurable

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/JGRP-1985?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on JGRP-1985: ------------------------------------ I didn't actually see header copying in my tests, I was just thinking of {{FRAG2}} because you mentioned fragmentation in the description. But WildFly always uses {{FORK}}, so a default of 4 should be better even without fragmentation. > Message: make initial size of headers configurable > -------------------------------------------------- > > Key: JGRP-1985 > URL: https://issues.jboss.org/browse/JGRP-1985 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.7 > > > By default a message creates a {{Headers}} instance of 3. This is usually enough (transport, either {{NAKACK2}} or {{UNICAST3}}, and possibly fragmentation). However, if a message needs 4 or more headers, there's a resize which is an additional copy of 2 small arrays. > Goal: make the initial headers size configurable. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1016) Too much memory consumption while running code on drools6.

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1016?page=com.atlassian.jira.plugi... ] Mario Fusco commented on DROOLS-1016: ------------------------------------- I'm not aware of any reason why the heap memory occupation of drools 6 should be more than the double of the one used by 5. It's hard to reply without a reproducer, can you provide one? > Too much memory consumption while running code on drools6. > ---------------------------------------------------------- > > Key: DROOLS-1016 > URL: https://issues.jboss.org/browse/DROOLS-1016 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.2.0.Final > Reporter: Vivek Hingorani > Assignee: Mario Fusco > > The memory usage on drools6 is far more then drools 5. Can we run the drools6 code with Rete algorithm? > We recently migrated our project from Drools 5.3.0.Final version to Drools 6.2.0.Final version. In production we can see a significant increase in the memory consumption per node. we are using java 1.7. We increased the permgen space as well for drools6 from 0.5 GB to 1 GB but still the increase is too much. Is there any solution for the same. > Drools5 memory usage was 0.5GB per node with 0.5GB permgen space > Drools6 memory usage is 1.3GB per node with 1GB permgen space. > Node here is a jvm as we are using oracle coherence. > If further details are needed , let me know. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1267) Changing the max-history attribute value for configuration-changes fails

by ehsavoie Hugonnet (JIRA)

ehsavoie Hugonnet created WFCORE-1267: ----------------------------------------- Summary: Changing the max-history attribute value for configuration-changes fails Key: WFCORE-1267 URL: https://issues.jboss.org/browse/WFCORE-1267 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 2.0.5.Final Reporter: ehsavoie Hugonnet Assignee: ehsavoie Hugonnet [standalone@localhost:9990 /] /core-service=management/service=configuration-changes:write-attribute(name=max-history,value=20) { "outcome" => "failed", "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0188: Stage MODEL is already complete", "rolled-back" => true } -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-123) TCP reconnect will only attempt to reconnect once

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-123?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on LOGMGR-123: ------------------------------------------------ baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1295665|https://bugzilla.redhat.com/show_bug.cgi?id=1295665] from NEW to MODIFIED > TCP reconnect will only attempt to reconnect once > ------------------------------------------------- > > Key: LOGMGR-123 > URL: https://issues.jboss.org/browse/LOGMGR-123 > Project: JBoss Log Manager > Issue Type: Bug > Reporter: James Perkins > Assignee: James Perkins > Fix For: 1.5.5.Final, 2.0.2.Final, 2.1.0.Beta1 > > > The same thread used in an attempt to start a reconnect. This means a reconnect will only be attempted and reconnected once. If another disconnect happens starting the reconnect fails as the same thread cannot be restarted. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-123) TCP reconnect will only attempt to reconnect once

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-123?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated LOGMGR-123: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1295660, https://bugzilla.redhat.com/show_bug.cgi?id=1295665 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1295660) > TCP reconnect will only attempt to reconnect once > ------------------------------------------------- > > Key: LOGMGR-123 > URL: https://issues.jboss.org/browse/LOGMGR-123 > Project: JBoss Log Manager > Issue Type: Bug > Reporter: James Perkins > Assignee: James Perkins > Fix For: 1.5.5.Final, 2.0.2.Final, 2.1.0.Beta1 > > > The same thread used in an attempt to start a reconnect. This means a reconnect will only be attempted and reconnected once. If another disconnect happens starting the reconnect fails as the same thread cannot be restarted. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5931) HTTP connection is getting closed after 5 mins

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-5931?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-5931. ---------------------------------- Resolution: Rejected Undertow has no such timeout, as far as I can see this is an apache issue not a Wildfly one > HTTP connection is getting closed after 5 mins > ---------------------------------------------- > > Key: WFLY-5931 > URL: https://issues.jboss.org/browse/WFLY-5931 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 9.0.1.Final > Environment: Wildfly 9.0.1 + Linux > Reporter: Rakesh Kumar > Assignee: Stuart Douglas > Priority: Critical > Fix For: 9.x.x TBD > > > HTTP connection is getting closed after 5 mins with Linux + Wildfly 9.0.1 and throws broken pipe exception after the request is processed, It works fine in windows + Wildfly 9.0.1. > I tried to increase keepalive timeout using the following alternatives. > • Update values in httpd.conf from 300 seconds to 1500 seconds > • Add KeepAliveTimeout response header in standalone.xml > • Add header in response using “response.addHeader("Keep-Alive", "timeout=180000");” > • Updated jsp to add ("Keep-Alive", "timeout=180000" ) in response header. > None of the above alternatives worked. > Error message : > 2015-10-23 18:46:47,250 ERROR [default task-29] [RequestServlet] Unknown exception detected: java.io.IOException: Broken pipe > at sun.nio.ch.FileDispatcherImpl.writev0(Native Method) [rt.jar:1.7.0_45] > at sun.nio.ch.SocketDispatcher.writev(SocketDispatcher.java:51) [rt.jar:1.7.0_45] > at sun.nio.ch.IOUtil.write(IOUtil.java:148) [rt.jar:1.7.0_45] > at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:524) [rt.jar:1.7.0_45] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-123) TCP reconnect will only attempt to reconnect once

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-123?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on LOGMGR-123: ------------------------------------------------ baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1295660|https://bugzilla.redhat.com/show_bug.cgi?id=1295660] from NEW to MODIFIED > TCP reconnect will only attempt to reconnect once > ------------------------------------------------- > > Key: LOGMGR-123 > URL: https://issues.jboss.org/browse/LOGMGR-123 > Project: JBoss Log Manager > Issue Type: Bug > Reporter: James Perkins > Assignee: James Perkins > Fix For: 1.5.5.Final, 2.0.2.Final, 2.1.0.Beta1 > > > The same thread used in an attempt to start a reconnect. This means a reconnect will only be attempted and reconnected once. If another disconnect happens starting the reconnect fails as the same thread cannot be restarted. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2016