[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" />
> <!-- dependency for richfaces -->
> <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)
8 years, 5 months
[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)
8 years, 5 months
[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)
8 years, 5 months
[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)
8 years, 5 months
[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)
8 years, 5 months
[JBoss JIRA] (LOGMGR-122) Syslog handler is not generating correct timestamp format
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-122?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on LOGMGR-122:
------------------------------------------------
baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1295657|https://bugzilla.redhat.com/show_bug.cgi?id=1295657] from NEW to MODIFIED
> Syslog handler is not generating correct timestamp format
> ---------------------------------------------------------
>
> Key: LOGMGR-122
> URL: https://issues.jboss.org/browse/LOGMGR-122
> Project: JBoss Log Manager
> Issue Type: Bug
> Affects Versions: 2.0.0.Final
> Environment: Wildfly 9.0.1.Final, Oracle JRE 1.8.0_11, CentOS 6
> Reporter: Ricardo Kagawa
> Assignee: James Perkins
> Fix For: 1.4.4.Final, 1.5.5.Final, 2.0.1.Final, 2.1.0.Beta1
>
>
> The Syslog handler is outputting an extra zero before the month in the header timestamp for RFC5424, specifically for October.
> Checking [Github|https://github.com/jboss-logging/jboss-logmanager/blob/master/src/...], I have noticed that the month number is tested for double digit before being offset, so a zero is added for October (month 9 for java.util.Calendar), then offset for proper display (month "10" for ISO8601), resulting in a three-digit month ("010").
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months