[JBoss JIRA] (JBLOGGING-94) JBoss Logging does not detect log4j 2.0
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/JBLOGGING-94?page=com.atlassian.jira.plug... ]
David Lloyd reassigned JBLOGGING-94:
------------------------------------
Assignee: James Perkins (was: David Lloyd)
James could you whip up a patch for this? Thanks.
> JBoss Logging does not detect log4j 2.0
> ---------------------------------------
>
> Key: JBLOGGING-94
> URL: https://issues.jboss.org/browse/JBLOGGING-94
> Project: JBoss Logging
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: jboss-logging-log4j
> Affects Versions: 3.1.2.GA
> Environment: Hibernate
> Reporter: Henry Clout
> Assignee: James Perkins
>
> The class org.jboss.logging.LoggerProviders checks for the presence of log4j using the code:
> {code}
> private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
> Class.forName("org.apache.log4j.LogManager", true, cl);
> // JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
> Class.forName("org.apache.log4j.Hierarchy", true, cl);
> return new Log4jLoggerProvider();
> }
> {code}
> However, despite having the log4j-1.2-api-2.0.jar bridge included, this fails as the class org.apache.log4j.Hierarchy is not present in log4j 2.0.
> I worked around this by forcing JBoss logging to use slf4j (which is then proxied to log4j) by setting the -Dorg.jboss.logging.provider=slf4j option.
> As a proper fix, however, how about checking for a class that is included in log4j 1.2, 2.0 but not slf4j? org.apache.log4j.config.PropertySetter seems to tick the box.
> I tested changing the afore mentioned method to:
> {code}
> private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
> Class.forName("org.apache.log4j.LogManager", true, cl);
> // JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
> Class.forName("org.apache.log4j.config.PropertySetter", true, cl);
> return new Log4jLoggerProvider();
> }
> {code}
> And indeed I started receiving logging messages from Hibernate (via JBoss logging.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (AS7-6727) Modular build not in sync with modules directory structure
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6727?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6727:
----------------------------------------------
Pavel Jelinek <pjelinek(a)redhat.com> changed the Status of [bug 947145|https://bugzilla.redhat.com/show_bug.cgi?id=947145] from ON_QA to VERIFIED
> Modular build not in sync with modules directory structure
> ----------------------------------------------------------
>
> Key: AS7-6727
> URL: https://issues.jboss.org/browse/AS7-6727
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Labels: Karaf
>
> {code}
> [echo] Static modules: [org.jboss.as.standalone,org.jboss.as.domain-http-error-context,,, org.jboss.logging, org.jboss.vfs, org.slf4j, org.jboss.logging.jul-to-slf4j-stub]
> [java] Exception in thread "main" java.io.FileNotFoundException: /Users/tdiesler/git/jboss-as/build-modular/../build/src/main/resources/modules/org/jboss/as/logging/main/module.xml (No such file or directory)
> [java] at java.io.FileInputStream.open(Native Method)
> [java] at java.io.FileInputStream.<init>(FileInputStream.java:138)
> [java] at org.jboss.as.config.assembly.ModuleParser.parse(ModuleParser.java:61)
> [java] at org.jboss.as.config.assembly.GenerateModulesDefinition.processModuleDependency(GenerateModulesDefinition.java:193)
> [java] at org.jboss.as.config.assembly.GenerateModulesDefinition.process(GenerateModulesDefinition.java:130)
> [java] at org.jboss.as.config.assembly.GenerateModulesDefinition.main(GenerateModulesDefinition.java:104)
> [java] Java Result: 1
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (AS7-6727) Modular build not in sync with modules directory structure
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6727?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6727:
----------------------------------------------
Pavel Jelinek <pjelinek(a)redhat.com> made a comment on [bug 947145|https://bugzilla.redhat.com/show_bug.cgi?id=947145]
In EAP 6.1.0.ER5 the build-modular ant config and other files changed to meet new modules directory structure.
> Modular build not in sync with modules directory structure
> ----------------------------------------------------------
>
> Key: AS7-6727
> URL: https://issues.jboss.org/browse/AS7-6727
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Labels: Karaf
>
> {code}
> [echo] Static modules: [org.jboss.as.standalone,org.jboss.as.domain-http-error-context,,, org.jboss.logging, org.jboss.vfs, org.slf4j, org.jboss.logging.jul-to-slf4j-stub]
> [java] Exception in thread "main" java.io.FileNotFoundException: /Users/tdiesler/git/jboss-as/build-modular/../build/src/main/resources/modules/org/jboss/as/logging/main/module.xml (No such file or directory)
> [java] at java.io.FileInputStream.open(Native Method)
> [java] at java.io.FileInputStream.<init>(FileInputStream.java:138)
> [java] at org.jboss.as.config.assembly.ModuleParser.parse(ModuleParser.java:61)
> [java] at org.jboss.as.config.assembly.GenerateModulesDefinition.processModuleDependency(GenerateModulesDefinition.java:193)
> [java] at org.jboss.as.config.assembly.GenerateModulesDefinition.process(GenerateModulesDefinition.java:130)
> [java] at org.jboss.as.config.assembly.GenerateModulesDefinition.main(GenerateModulesDefinition.java:104)
> [java] Java Result: 1
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (JBLOGGING-94) JBoss Logging does not detect log4j 2.0
by Henry Clout (JIRA)
[ https://issues.jboss.org/browse/JBLOGGING-94?page=com.atlassian.jira.plug... ]
Henry Clout updated JBLOGGING-94:
---------------------------------
Description:
The class org.jboss.logging.LoggerProviders checks for the presence of log4j using the code:
{code}
private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
Class.forName("org.apache.log4j.LogManager", true, cl);
// JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
Class.forName("org.apache.log4j.Hierarchy", true, cl);
return new Log4jLoggerProvider();
}
{code}
However, despite having the log4j-1.2-api-2.0.jar bridge included, this fails as the class org.apache.log4j.Hierarchy is not present in log4j 2.0.
I worked around this by forcing JBoss logging to use slf4j (which is then proxied to log4j) by setting the -Dorg.jboss.logging.provider=slf4j option.
As a proper fix, however, how about checking for a class that is included in log4j 1.2, 2.0 but not slf4j? org.apache.log4j.config.PropertySetter seems to tick the box.
I tested changing the afore mentioned method to:
{code}
private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
Class.forName("org.apache.log4j.LogManager", true, cl);
// JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
Class.forName("org.apache.log4j.config.PropertySetter", true, cl);
return new Log4jLoggerProvider();
}
{code}
And indeed I started receiving logging messages from Hibernate (via JBoss logging.)
was:
The class org.jboss.logging.LoggerProviders checkes for the presence of log4j using the code:
{code}
private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
Class.forName("org.apache.log4j.LogManager", true, cl);
// JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
Class.forName("org.apache.log4j.Hierarchy", true, cl);
return new Log4jLoggerProvider();
}
{code}
However, despite having the log4j-1.2-api-2.0.jar bridge included, this fails as the class org.apache.log4j.Hierarchy is not present in log4j 2.0.
I worked around this by forcing JBoss logging to use slf4j (which is then proxied to log4j) by setting the -Dorg.jboss.logging.provider=slf4j option.
As a proper fix, however, how about checking for a class that is included in log4j 1.2, 2.0 but not slf4j? org.apache.log4j.config.PropertySetter seems to tick the box.
I tested changing the afore mentioned method to:
{code}
private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
Class.forName("org.apache.log4j.LogManager", true, cl);
// JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
Class.forName("org.apache.log4j.config.PropertySetter", true, cl);
return new Log4jLoggerProvider();
}
{code}
And indeed I started receiving logging messages from Hibernate (via JBoss logging.)
> JBoss Logging does not detect log4j 2.0
> ---------------------------------------
>
> Key: JBLOGGING-94
> URL: https://issues.jboss.org/browse/JBLOGGING-94
> Project: JBoss Logging
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: jboss-logging-log4j
> Affects Versions: 3.1.2.GA
> Environment: Hibernate
> Reporter: Henry Clout
> Assignee: David Lloyd
>
> The class org.jboss.logging.LoggerProviders checks for the presence of log4j using the code:
> {code}
> private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
> Class.forName("org.apache.log4j.LogManager", true, cl);
> // JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
> Class.forName("org.apache.log4j.Hierarchy", true, cl);
> return new Log4jLoggerProvider();
> }
> {code}
> However, despite having the log4j-1.2-api-2.0.jar bridge included, this fails as the class org.apache.log4j.Hierarchy is not present in log4j 2.0.
> I worked around this by forcing JBoss logging to use slf4j (which is then proxied to log4j) by setting the -Dorg.jboss.logging.provider=slf4j option.
> As a proper fix, however, how about checking for a class that is included in log4j 1.2, 2.0 but not slf4j? org.apache.log4j.config.PropertySetter seems to tick the box.
> I tested changing the afore mentioned method to:
> {code}
> private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
> Class.forName("org.apache.log4j.LogManager", true, cl);
> // JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
> Class.forName("org.apache.log4j.config.PropertySetter", true, cl);
> return new Log4jLoggerProvider();
> }
> {code}
> And indeed I started receiving logging messages from Hibernate (via JBoss logging.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (JBLOGGING-94) JBoss Logging does not detect log4j 2.0
by Henry Clout (JIRA)
[ https://issues.jboss.org/browse/JBLOGGING-94?page=com.atlassian.jira.plug... ]
Henry Clout updated JBLOGGING-94:
---------------------------------
Description:
The class org.jboss.logging.LoggerProviders checkes for the presence of log4j using the code:
{code}
private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
Class.forName("org.apache.log4j.LogManager", true, cl);
// JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
Class.forName("org.apache.log4j.Hierarchy", true, cl);
return new Log4jLoggerProvider();
}
{code}
However, despite having the log4j-1.2-api-2.0.jar bridge included, this fails as the class org.apache.log4j.Hierarchy is not present in log4j 2.0.
I worked around this by forcing JBoss logging to use slf4j (which is then proxied to log4j) by setting the -Dorg.jboss.logging.provider=slf4j option.
As a proper fix, however, how about checking for a class that is included in log4j 1.2, 2.0 but not slf4j? org.apache.log4j.config.PropertySetter seems to tick the box.
I tested changing the afore mentioned method to:
private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
Class.forName("org.apache.log4j.LogManager", true, cl);
// JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
Class.forName("org.apache.log4j.config.PropertySetter", true, cl);
return new Log4jLoggerProvider();
}
And indeed I started receiving logging messages from Hibernate (via JBoss logging.)
was:
The class org.jboss.logging.LoggerProviders checkes for the presence of log4j using the code:
private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
Class.forName("org.apache.log4j.LogManager", true, cl);
// JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
Class.forName("org.apache.log4j.Hierarchy", true, cl);
return new Log4jLoggerProvider();
}
However, despite having the log4j-1.2-api-2.0.jar bridge included, this fails as the class org.apache.log4j.Hierarchy is not present in log4j 2.0.
I worked around this by forcing JBoss logging to use slf4j (which is then proxied to log4j) by setting the -Dorg.jboss.logging.provider=slf4j option.
As a proper fix, however, how about checking for a class that is included in log4j 1.2, 2.0 but not slf4j? org.apache.log4j.config.PropertySetter seems to tick the box.
I tested changing the afore mentioned method to:
private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
Class.forName("org.apache.log4j.LogManager", true, cl);
// JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
Class.forName("org.apache.log4j.config.PropertySetter", true, cl);
return new Log4jLoggerProvider();
}
And indeed I started receiving logging messages from Hibernate (via JBoss logging.)
> JBoss Logging does not detect log4j 2.0
> ---------------------------------------
>
> Key: JBLOGGING-94
> URL: https://issues.jboss.org/browse/JBLOGGING-94
> Project: JBoss Logging
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: jboss-logging-log4j
> Affects Versions: 3.1.2.GA
> Environment: Hibernate
> Reporter: Henry Clout
> Assignee: David Lloyd
>
> The class org.jboss.logging.LoggerProviders checkes for the presence of log4j using the code:
> {code}
> private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
> Class.forName("org.apache.log4j.LogManager", true, cl);
> // JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
> Class.forName("org.apache.log4j.Hierarchy", true, cl);
> return new Log4jLoggerProvider();
> }
> {code}
> However, despite having the log4j-1.2-api-2.0.jar bridge included, this fails as the class org.apache.log4j.Hierarchy is not present in log4j 2.0.
> I worked around this by forcing JBoss logging to use slf4j (which is then proxied to log4j) by setting the -Dorg.jboss.logging.provider=slf4j option.
> As a proper fix, however, how about checking for a class that is included in log4j 1.2, 2.0 but not slf4j? org.apache.log4j.config.PropertySetter seems to tick the box.
> I tested changing the afore mentioned method to:
> private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
> Class.forName("org.apache.log4j.LogManager", true, cl);
> // JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
> Class.forName("org.apache.log4j.config.PropertySetter", true, cl);
> return new Log4jLoggerProvider();
> }
> And indeed I started receiving logging messages from Hibernate (via JBoss logging.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (JBLOGGING-94) JBoss Logging does not detect log4j 2.0
by Henry Clout (JIRA)
[ https://issues.jboss.org/browse/JBLOGGING-94?page=com.atlassian.jira.plug... ]
Henry Clout updated JBLOGGING-94:
---------------------------------
Description:
The class org.jboss.logging.LoggerProviders checkes for the presence of log4j using the code:
{code}
private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
Class.forName("org.apache.log4j.LogManager", true, cl);
// JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
Class.forName("org.apache.log4j.Hierarchy", true, cl);
return new Log4jLoggerProvider();
}
{code}
However, despite having the log4j-1.2-api-2.0.jar bridge included, this fails as the class org.apache.log4j.Hierarchy is not present in log4j 2.0.
I worked around this by forcing JBoss logging to use slf4j (which is then proxied to log4j) by setting the -Dorg.jboss.logging.provider=slf4j option.
As a proper fix, however, how about checking for a class that is included in log4j 1.2, 2.0 but not slf4j? org.apache.log4j.config.PropertySetter seems to tick the box.
I tested changing the afore mentioned method to:
{code}
private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
Class.forName("org.apache.log4j.LogManager", true, cl);
// JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
Class.forName("org.apache.log4j.config.PropertySetter", true, cl);
return new Log4jLoggerProvider();
}
{code}
And indeed I started receiving logging messages from Hibernate (via JBoss logging.)
was:
The class org.jboss.logging.LoggerProviders checkes for the presence of log4j using the code:
{code}
private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
Class.forName("org.apache.log4j.LogManager", true, cl);
// JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
Class.forName("org.apache.log4j.Hierarchy", true, cl);
return new Log4jLoggerProvider();
}
{code}
However, despite having the log4j-1.2-api-2.0.jar bridge included, this fails as the class org.apache.log4j.Hierarchy is not present in log4j 2.0.
I worked around this by forcing JBoss logging to use slf4j (which is then proxied to log4j) by setting the -Dorg.jboss.logging.provider=slf4j option.
As a proper fix, however, how about checking for a class that is included in log4j 1.2, 2.0 but not slf4j? org.apache.log4j.config.PropertySetter seems to tick the box.
I tested changing the afore mentioned method to:
private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
Class.forName("org.apache.log4j.LogManager", true, cl);
// JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
Class.forName("org.apache.log4j.config.PropertySetter", true, cl);
return new Log4jLoggerProvider();
}
And indeed I started receiving logging messages from Hibernate (via JBoss logging.)
> JBoss Logging does not detect log4j 2.0
> ---------------------------------------
>
> Key: JBLOGGING-94
> URL: https://issues.jboss.org/browse/JBLOGGING-94
> Project: JBoss Logging
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: jboss-logging-log4j
> Affects Versions: 3.1.2.GA
> Environment: Hibernate
> Reporter: Henry Clout
> Assignee: David Lloyd
>
> The class org.jboss.logging.LoggerProviders checkes for the presence of log4j using the code:
> {code}
> private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
> Class.forName("org.apache.log4j.LogManager", true, cl);
> // JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
> Class.forName("org.apache.log4j.Hierarchy", true, cl);
> return new Log4jLoggerProvider();
> }
> {code}
> However, despite having the log4j-1.2-api-2.0.jar bridge included, this fails as the class org.apache.log4j.Hierarchy is not present in log4j 2.0.
> I worked around this by forcing JBoss logging to use slf4j (which is then proxied to log4j) by setting the -Dorg.jboss.logging.provider=slf4j option.
> As a proper fix, however, how about checking for a class that is included in log4j 1.2, 2.0 but not slf4j? org.apache.log4j.config.PropertySetter seems to tick the box.
> I tested changing the afore mentioned method to:
> {code}
> private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
> Class.forName("org.apache.log4j.LogManager", true, cl);
> // JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
> Class.forName("org.apache.log4j.config.PropertySetter", true, cl);
> return new Log4jLoggerProvider();
> }
> {code}
> And indeed I started receiving logging messages from Hibernate (via JBoss logging.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (JBLOGGING-94) JBoss Logging does not detect log4j 2.0
by Henry Clout (JIRA)
Henry Clout created JBLOGGING-94:
------------------------------------
Summary: JBoss Logging does not detect log4j 2.0
Key: JBLOGGING-94
URL: https://issues.jboss.org/browse/JBLOGGING-94
Project: JBoss Logging
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jboss-logging-log4j
Affects Versions: 3.1.2.GA
Environment: Hibernate
Reporter: Henry Clout
Assignee: David Lloyd
The class org.jboss.logging.LoggerProviders checkes for the presence of log4j using the code:
private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
Class.forName("org.apache.log4j.LogManager", true, cl);
// JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
Class.forName("org.apache.log4j.Hierarchy", true, cl);
return new Log4jLoggerProvider();
}
However, despite having the log4j-1.2-api-2.0.jar bridge included, this fails as the class org.apache.log4j.Hierarchy is not present in log4j 2.0.
I worked around this by forcing JBoss logging to use slf4j (which is then proxied to log4j) by setting the -Dorg.jboss.logging.provider=slf4j option.
As a proper fix, however, how about checking for a class that is included in log4j 1.2, 2.0 but not slf4j? org.apache.log4j.config.PropertySetter seems to tick the box.
I tested changing the afore mentioned method to:
private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
Class.forName("org.apache.log4j.LogManager", true, cl);
// JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
Class.forName("org.apache.log4j.config.PropertySetter", true, cl);
return new Log4jLoggerProvider();
}
And indeed I started receiving logging messages from Hibernate (via JBoss logging.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (JGRP-1609) Poor performance of TCP/TCPGOSSIP when a node fails
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1609?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1609.
----------------------------
Resolution: Done
Closing the issue. Feel free to reopen if the solution doesn't work for you. Since I'll release 3.3. by May 8, if you reopen it I might push it into 3.4.
> Poor performance of TCP/TCPGOSSIP when a node fails
> ---------------------------------------------------
>
> Key: JGRP-1609
> URL: https://issues.jboss.org/browse/JGRP-1609
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.1, 3.3
> Environment: Linux
> Reporter: Ramky Kandula
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> I have TCP transport with TCPGOSSIP for discovery. The exact config is same as tcp.xml but has TCPGOSSIP instead of TCPPING and MERGE3 instead of MERGE2.
> When I run Mperf with this stack on nodes A,B,C and in the middle of the test, shutdown the network interface of a node, say C, C is removed from the view after FD interval but the subsequent performance is very poor, in tens of KB rather than tens to hundrend MB.
> What I observed is that the TrasnferQueueBundler in the TP keeps trying to connect to node C for every multicast and times out.
> When I disable bundling with 3.1, the Mperf sender thread gets into the same condition for every multicast.
> Logically, once the view has changed, we want the nodes A and B to continue to perform at the same rate they were doing before the network interface for C is shutdown.
> The following stack trace shows where it is doing the connect to node C with bundling enabled.
> "TransferQueueBundler,mperf,lnx1-60691" prio=10 tid=0x00002aaab4024000 nid=0x6f77 runnable [0x00000000420f7000]
> java.lang.Thread.State: RUNNABLE
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
> - locked <0x00000000f223f0f0> (a java.net.SocksSocketImpl)
> at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
> at java.net.Socket.connect(Socket.java:529)
> at org.jgroups.util.Util.connect(Util.java:354)
> at org.jgroups.blocks.TCPConnectionMap$TCPConnection.connect(TCPConnectionMap.java:408)
> at org.jgroups.blocks.TCPConnectionMap$Mapper.getConnection(TCPConnectionMap.java:775)
> at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:184)
> at org.jgroups.protocols.TCP.send(TCP.java:56)
> at org.jgroups.protocols.BasicTCP.sendUnicast(BasicTCP.java:99)
> at org.jgroups.protocols.TP.sendToAllPhysicalAddresses(TP.java:1611)
> at org.jgroups.protocols.BasicTCP.sendMulticast(BasicTCP.java:94)
> at org.jgroups.protocols.TP.doSend(TP.java:1560)
> at org.jgroups.protocols.TP$TransferQueueBundler.sendBundledMessages(TP.java:2329)
> at org.jgroups.protocols.TP$TransferQueueBundler.sendMessages(TP.java:2261)
> at org.jgroups.protocols.TP$TransferQueueBundler.run(TP.java:2246)
> at java.lang.Thread.run(Thread.java:662)
> The netstat also shows it keeps trying to connect to that node C (192.20.20.33)
> [root@lnx1 ~]# netstat -an| grep 7800
> tcp 0 0 192.20.20.233:7800 0.0.0.0:* LISTEN
> tcp 0 1 192.20.20.233:53070 192.20.20.33:7800 SYN_SENT
> tcp 0 0 192.20.20.233:34237 192.20.20.133:7800 ESTABLISHED
> [root@lnx1 ~]# netstat -an| grep 7800
> tcp 0 0 192.20.20.233:7800 0.0.0.0:* LISTEN
> tcp 0 1 192.20.20.233:36345 192.20.20.33:7800 SYN_SENT
> tcp 0 0 192.20.20.233:34237 192.20.20.133:7800 ESTABLISHED
> [root@lnx1 ~]# netstat -an| grep 7800
> tcp 0 0 192.20.20.233:7800 0.0.0.0:* LISTEN
> tcp 0 1 192.20.20.233:51724 192.20.20.33:7800 SYN_SENT
> tcp 0 113287 192.20.20.233:34237 192.20.20.133:7800 ESTABLISHED
> [root@lnx1 ~]# netstat -an| grep 7800
> tcp 0 0 192.20.20.233:7800 0.0.0.0:* LISTEN
> tcp 0 1 192.20.20.233:51724 192.20.20.33:7800 SYN_SENT
> tcp 0 0 192.20.20.233:34237 192.20.20.133:7800 ESTABLISHED
> [root@lnx1 ~]# netstat -an| grep 7800
> tcp 0 0 192.20.20.233:7800 0.0.0.0:* LISTEN
> tcp 0 1 192.20.20.233:35389 192.20.20.33:7800 SYN_SENT
> tcp 0 0 192.20.20.233:34237 192.20.20.133:7800 ESTABLISHED
> With bundling disabled (had to use 3.1 version), the following stack trace shows where sender thread keeps trying to connect to node C.
> "sender-0" prio=10 tid=0x000000004cc1e800 nid=0x429 runnable [0x00002afe67973000]
> java.lang.Thread.State: RUNNABLE
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(Unknown Source)
> - locked <0x00000000ec6046a0> (a java.net.SocksSocketImpl)
> at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
> at java.net.PlainSocketImpl.connect(Unknown Source)
> at java.net.SocksSocketImpl.connect(Unknown Source)
> at java.net.Socket.connect(Unknown Source)
> at org.jgroups.util.Util.connect(Util.java:305)
> at org.jgroups.blocks.TCPConnectionMap$TCPConnection.<init>(TCPConnectionMap.java:388)
> at org.jgroups.blocks.TCPConnectionMap$Mapper.getConnection(TCPConnectionMap.java:785)
> at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:174)
> at org.jgroups.protocols.TCP.send(TCP.java:56)
> at org.jgroups.protocols.BasicTCP.sendUnicast(BasicTCP.java:86)
> at org.jgroups.protocols.TP.sendToAllPhysicalAddresses(TP.java:1348)
> at org.jgroups.protocols.BasicTCP.sendMulticast(BasicTCP.java:81)
> at org.jgroups.protocols.TP.doSend(TP.java:1296)
> at org.jgroups.protocols.TP.send(TP.java:1285)
> at org.jgroups.protocols.TP.down(TP.java:1143)
> at org.jgroups.protocols.Discovery.down(Discovery.java:573)
> at org.jgroups.protocols.MERGE3.down(MERGE3.java:242)
> at org.jgroups.protocols.FD.down(FD.java:308)
> at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:80)
> at org.jgroups.protocols.pbcast.NAKACK.send(NAKACK.java:667)
> at org.jgroups.protocols.pbcast.NAKACK.send(NAKACK.java:678)
> at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:459)
> at org.jgroups.protocols.UNICAST2.down(UNICAST2.java:531)
> at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:328)
> at org.jgroups.protocols.pbcast.GMS.down(GMS.java:968)
> at org.jgroups.protocols.FlowControl.down(FlowControl.java:351)
> at org.jgroups.protocols.MFC.handleDownMessage(MFC.java:116)
> at org.jgroups.protocols.FlowControl.down(FlowControl.java:341)
> at org.jgroups.protocols.FRAG2.down(FRAG2.java:147)
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1025)
> at org.jgroups.JChannel.down(JChannel.java:729)
> at org.jgroups.JChannel.send(JChannel.java:445)
> at org.jgroups.tests.perf.MPerf$Sender.run(MPerf.java:564)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (JGRP-1609) Poor performance of TCP/TCPGOSSIP when a node fails
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1609?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1609:
--------------------------------
I tried this, didn't use ifdown but kill -suspend or kill -3/9, and it worked. A few things though to make it work:
# Do *not* enable TCPGOSSIP.return_entire_cache
# FD's timeout will be needed to exclude C
# GossipRouter must be started with -expiry <millisecs to expiry>
You can dump the GossipRouters cache with JMX, or with "java org.jgroups.tests.RouterStubGet -cluster mperf". After expiry ms max, C's entry should be removed.
After FD kicks in (or FD_SOCK, if you CTRL-C the process), there should be a view change excluding C. After this, there should no connections be made to C any longer.
MERGE3 does contact the GossipRouter to see if there are partitions, but if -expiry is *not* defined, the entry for C will never get removed and therefore we'll tyr forever to contact C.
Let me know if this works.
> Poor performance of TCP/TCPGOSSIP when a node fails
> ---------------------------------------------------
>
> Key: JGRP-1609
> URL: https://issues.jboss.org/browse/JGRP-1609
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.1, 3.3
> Environment: Linux
> Reporter: Ramky Kandula
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> I have TCP transport with TCPGOSSIP for discovery. The exact config is same as tcp.xml but has TCPGOSSIP instead of TCPPING and MERGE3 instead of MERGE2.
> When I run Mperf with this stack on nodes A,B,C and in the middle of the test, shutdown the network interface of a node, say C, C is removed from the view after FD interval but the subsequent performance is very poor, in tens of KB rather than tens to hundrend MB.
> What I observed is that the TrasnferQueueBundler in the TP keeps trying to connect to node C for every multicast and times out.
> When I disable bundling with 3.1, the Mperf sender thread gets into the same condition for every multicast.
> Logically, once the view has changed, we want the nodes A and B to continue to perform at the same rate they were doing before the network interface for C is shutdown.
> The following stack trace shows where it is doing the connect to node C with bundling enabled.
> "TransferQueueBundler,mperf,lnx1-60691" prio=10 tid=0x00002aaab4024000 nid=0x6f77 runnable [0x00000000420f7000]
> java.lang.Thread.State: RUNNABLE
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
> - locked <0x00000000f223f0f0> (a java.net.SocksSocketImpl)
> at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
> at java.net.Socket.connect(Socket.java:529)
> at org.jgroups.util.Util.connect(Util.java:354)
> at org.jgroups.blocks.TCPConnectionMap$TCPConnection.connect(TCPConnectionMap.java:408)
> at org.jgroups.blocks.TCPConnectionMap$Mapper.getConnection(TCPConnectionMap.java:775)
> at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:184)
> at org.jgroups.protocols.TCP.send(TCP.java:56)
> at org.jgroups.protocols.BasicTCP.sendUnicast(BasicTCP.java:99)
> at org.jgroups.protocols.TP.sendToAllPhysicalAddresses(TP.java:1611)
> at org.jgroups.protocols.BasicTCP.sendMulticast(BasicTCP.java:94)
> at org.jgroups.protocols.TP.doSend(TP.java:1560)
> at org.jgroups.protocols.TP$TransferQueueBundler.sendBundledMessages(TP.java:2329)
> at org.jgroups.protocols.TP$TransferQueueBundler.sendMessages(TP.java:2261)
> at org.jgroups.protocols.TP$TransferQueueBundler.run(TP.java:2246)
> at java.lang.Thread.run(Thread.java:662)
> The netstat also shows it keeps trying to connect to that node C (192.20.20.33)
> [root@lnx1 ~]# netstat -an| grep 7800
> tcp 0 0 192.20.20.233:7800 0.0.0.0:* LISTEN
> tcp 0 1 192.20.20.233:53070 192.20.20.33:7800 SYN_SENT
> tcp 0 0 192.20.20.233:34237 192.20.20.133:7800 ESTABLISHED
> [root@lnx1 ~]# netstat -an| grep 7800
> tcp 0 0 192.20.20.233:7800 0.0.0.0:* LISTEN
> tcp 0 1 192.20.20.233:36345 192.20.20.33:7800 SYN_SENT
> tcp 0 0 192.20.20.233:34237 192.20.20.133:7800 ESTABLISHED
> [root@lnx1 ~]# netstat -an| grep 7800
> tcp 0 0 192.20.20.233:7800 0.0.0.0:* LISTEN
> tcp 0 1 192.20.20.233:51724 192.20.20.33:7800 SYN_SENT
> tcp 0 113287 192.20.20.233:34237 192.20.20.133:7800 ESTABLISHED
> [root@lnx1 ~]# netstat -an| grep 7800
> tcp 0 0 192.20.20.233:7800 0.0.0.0:* LISTEN
> tcp 0 1 192.20.20.233:51724 192.20.20.33:7800 SYN_SENT
> tcp 0 0 192.20.20.233:34237 192.20.20.133:7800 ESTABLISHED
> [root@lnx1 ~]# netstat -an| grep 7800
> tcp 0 0 192.20.20.233:7800 0.0.0.0:* LISTEN
> tcp 0 1 192.20.20.233:35389 192.20.20.33:7800 SYN_SENT
> tcp 0 0 192.20.20.233:34237 192.20.20.133:7800 ESTABLISHED
> With bundling disabled (had to use 3.1 version), the following stack trace shows where sender thread keeps trying to connect to node C.
> "sender-0" prio=10 tid=0x000000004cc1e800 nid=0x429 runnable [0x00002afe67973000]
> java.lang.Thread.State: RUNNABLE
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(Unknown Source)
> - locked <0x00000000ec6046a0> (a java.net.SocksSocketImpl)
> at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
> at java.net.PlainSocketImpl.connect(Unknown Source)
> at java.net.SocksSocketImpl.connect(Unknown Source)
> at java.net.Socket.connect(Unknown Source)
> at org.jgroups.util.Util.connect(Util.java:305)
> at org.jgroups.blocks.TCPConnectionMap$TCPConnection.<init>(TCPConnectionMap.java:388)
> at org.jgroups.blocks.TCPConnectionMap$Mapper.getConnection(TCPConnectionMap.java:785)
> at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:174)
> at org.jgroups.protocols.TCP.send(TCP.java:56)
> at org.jgroups.protocols.BasicTCP.sendUnicast(BasicTCP.java:86)
> at org.jgroups.protocols.TP.sendToAllPhysicalAddresses(TP.java:1348)
> at org.jgroups.protocols.BasicTCP.sendMulticast(BasicTCP.java:81)
> at org.jgroups.protocols.TP.doSend(TP.java:1296)
> at org.jgroups.protocols.TP.send(TP.java:1285)
> at org.jgroups.protocols.TP.down(TP.java:1143)
> at org.jgroups.protocols.Discovery.down(Discovery.java:573)
> at org.jgroups.protocols.MERGE3.down(MERGE3.java:242)
> at org.jgroups.protocols.FD.down(FD.java:308)
> at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:80)
> at org.jgroups.protocols.pbcast.NAKACK.send(NAKACK.java:667)
> at org.jgroups.protocols.pbcast.NAKACK.send(NAKACK.java:678)
> at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:459)
> at org.jgroups.protocols.UNICAST2.down(UNICAST2.java:531)
> at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:328)
> at org.jgroups.protocols.pbcast.GMS.down(GMS.java:968)
> at org.jgroups.protocols.FlowControl.down(FlowControl.java:351)
> at org.jgroups.protocols.MFC.handleDownMessage(MFC.java:116)
> at org.jgroups.protocols.FlowControl.down(FlowControl.java:341)
> at org.jgroups.protocols.FRAG2.down(FRAG2.java:147)
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1025)
> at org.jgroups.JChannel.down(JChannel.java:729)
> at org.jgroups.JChannel.send(JChannel.java:445)
> at org.jgroups.tests.perf.MPerf$Sender.run(MPerf.java:564)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months