January 2016 - jboss-jira - Jboss List Archives

[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)

10 years, 3 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)

10 years, 3 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)

10 years, 3 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)

10 years, 3 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 Bugzilla Update: Perform > 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)

10 years, 3 months

1
0
0 / 0

[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)

10 years, 3 months

1
0
0 / 0

[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 updated LOGMGR-122: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1295657 Bugzilla Update: Perform > 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)

10 years, 3 months

1
0
0 / 0

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

by Vivek Hingorani (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1016?page=com.atlassian.jira.plugi... ] Vivek Hingorani reopened DROOLS-1016: ------------------------------------- Please let us know the usage on heap space as that is more alarming with Drools6. As if the number of rules increases the usage of heap space will be more and that would create problem for our application. As rules will keep on increasing with new requirements. > 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)

10 years, 3 months

1
0
0 / 0

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

by Thomas Leung (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1016?page=com.atlassian.jira.plugi... ] Thomas Leung commented on DROOLS-1016: -------------------------------------- Thanks Mario, and how about the heap size? We observed there is used heap increased from 0.5GB to 1.3GB when migrating from Drools 5 to Drools 6. Will it be caused by phreak algorithm? Or any other suggestion that we can reduce the heap consumption? > 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)

10 years, 3 months

1
0
0 / 0

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

by Rakesh Kumar (JIRA)

[ https://issues.jboss.org/browse/WFLY-5931?page=com.atlassian.jira.plugin.... ] Rakesh Kumar updated WFLY-5931: ------------------------------- Affects Version/s: 9.0.1.Final (was: 9.0.2.Final) > 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)

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