[JBoss JIRA] (WFLY-4205) Undertow not detecting @HandlesTypes If the implentation class is inside EAR/lib
by Nick . (JIRA)
[ https://issues.jboss.org/browse/WFLY-4205?page=com.atlassian.jira.plugin.... ]
Nick . commented on WFLY-4205:
------------------------------
Loved it, thanks Stuart....
> Undertow not detecting @HandlesTypes If the implentation class is inside EAR/lib
> --------------------------------------------------------------------------------
>
> Key: WFLY-4205
> URL: https://issues.jboss.org/browse/WFLY-4205
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Environment: Wildfly 8.2.0 Final, EAR Deployment, Spring MVC, Ubuntu 14.04
> Reporter: Nick .
> Assignee: Stuart Douglas
> Labels: EAR, servlet3.0, spring-mvc
> Fix For: 9.0.0.Beta1
>
>
> Hi,
> I have spring mvc enabled web apps (20+ web apps) packaged as an EAR deployment. All my spring mvc related jar's are in my EAR/lib, i'm using SpringServletContainerInitializer (implementation of ServletContainerInitializer ) code as follows
> {code}
> @HandlesTypes(WebApplicationInitializer.class)
> public class SpringServletContainerInitializer implements ServletContainerInitializer {
> @Override
> public void onStartup(Set<Class<?>> webAppInitializerClasses, ServletContext servletContext)
> throws ServletException {
> List<WebApplicationInitializer> initializers = new LinkedList<WebApplicationInitializer>();
> if (webAppInitializerClasses != null) {
> for (Class<?> waiClass : webAppInitializerClasses) {
> // Be defensive: Some servlet containers provide us with invalid classes,
> // no matter what @HandlesTypes says...
> if (!waiClass.isInterface() && !Modifier.isAbstract(waiClass.getModifiers()) &&
> WebApplicationInitializer.class.isAssignableFrom(waiClass)) {
> try {
> initializers.add((WebApplicationInitializer) waiClass.newInstance());
> }
> catch (Throwable ex) {
> throw new ServletException("Failed to instantiate WebApplicationInitializer class", ex);
> }
> }
> }
> }
> if (initializers.isEmpty()) {
> servletContext.log("No Spring WebApplicationInitializer types detected on classpath");
> return;
> }
> AnnotationAwareOrderComparator.sort(initializers);
> servletContext.log("Spring WebApplicationInitializers detected on classpath: " + initializers);
> for (WebApplicationInitializer initializer : initializers) {
> initializer.onStartup(servletContext);
> }
> }
> }
> {code}
> But the @HandlesTypes(WebApplicationInitializer.class) are not getting detected from the EAR/lib
> Even i have tried adding the extracted the SPI from spring-web jar and added inside my war's WEB-INF/lib as a jar
> WEB-INF/lib/web-init-spi.jar which contains
> META-INF/services/javax.servlet.ServletContainerIntializer file with org.springframework.web.SpringServletContainerInitializer as an entry. This time its detecting SpringServletContainerInitializer but not detecting what defined in @HandlesTypes
> Its only working If i package all those spring mvc jars inside WEB-INF/lib then everything started working.
> I have no idea this is how the servlet specification works or its a wildfly issue but i see it as a problem for those who depends on Wildfly or similar EE Servers with an EAR deployment structure.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-3389) Error Connecting to WildFly via JMX
by Oliver Waeldrich (JIRA)
[ https://issues.jboss.org/browse/WFLY-3389?page=com.atlassian.jira.plugin.... ]
Oliver Waeldrich commented on WFLY-3389:
----------------------------------------
The stack trace indicates that Eclipse was started with a JDK < 1.7. java.net.InetSocketAddress.getHostString() was introduced with JDK 1.7. Use an sctual JDK to launch eclipse and the error should disappear.
> Error Connecting to WildFly via JMX
> -----------------------------------
>
> Key: WFLY-3389
> URL: https://issues.jboss.org/browse/WFLY-3389
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.1.0.CR1
> Environment: Windows 7 32 bit, behind a proxy that only lets IE through
> Reporter: R Veach
> Assignee: Darran Lofthouse
> Priority: Minor
> Attachments: console page.htm, eclipse error.txt, server.log
>
>
> When server is running through Eclipse Kepler, admin console is completely blank no error messages in the console and an Eclipse error dialog pops up.
> I tried running it outside eclipse using "standalone.bat" but get the same result. No error in the console, don't see the eclipse error anywhere, but the admin console doesn't show up.
> I have JBoss AS 7.1.1.Final and can access the console, but it may require a page refresh for it to fully display. Refreshing the page doesn't help in 8.1.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4288) error when trying to execute commands using jboss-cli.sh
by André Caldeira (JIRA)
[ https://issues.jboss.org/browse/WFLY-4288?page=com.atlassian.jira.plugin.... ]
André Caldeira commented on WFLY-4288:
--------------------------------------
just to add that we use jboss-cli regularly in our installation so that we can configure jboss according to each scenario that we have.
> error when trying to execute commands using jboss-cli.sh
> --------------------------------------------------------
>
> Key: WFLY-4288
> URL: https://issues.jboss.org/browse/WFLY-4288
> Project: WildFly
> Issue Type: Bug
> Affects Versions: JBoss AS7 7.2.0.Final
> Reporter: André Caldeira
> Assignee: Jason Greene
>
> Hi,
> I've configured jboss to use ssl, and after this change, sometimes, the command cannot be executed:
> [root@<node> ~]# /opt/oss/NSN-SQM-sqm_jboss/install/jboss-eap-6.2/bin/jboss-cli.sh --connect
> org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:284)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:262)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.modules.Module.run(Module.java:292)
> at org.jboss.modules.Main.main(Main.java:455)
> Caused by: org.jboss.as.cli.CommandLineException: The controller is not available at localhost:9990
> at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:969)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:808)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:784)
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:282)
> ... 8 more
> Caused by: java.io.IOException: java.net.ConnectException: JBAS012174: Could not connect to remote://localhost:9990. The connection failed
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:947)
> ... 11 more
> Caused by: java.net.ConnectException: JBAS012174: Could not connect to remote://localhost:9990. The connection failed
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:129)
> at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
> at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
> at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204)
> at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:160)
> at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:120)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> ... 13 more
> Caused by: java.net.ConnectException: Connection refused
> at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
> at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:739)
> at org.xnio.nio.NioXnioWorker$1.handleEvent(NioXnioWorker.java:322)
> at org.xnio.nio.NioXnioWorker$1.handleEvent(NioXnioWorker.java:318)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
> at org.xnio.nio.NioHandle.run(NioHandle.java:90)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:187)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:337)
> at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:80)
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:99)
> ... 23 more
> In server.log what I can see when it happens is:
> 17:08:30,279 ERROR [org.jboss.remoting.remote.connection] (Remoting "<node>:MANAGEMENT" read-1) JBREM000200: Remote connection failed: java.io.IOException: Broken pipe
> 17:08:42,071 ERROR [org.jboss.remoting.remote.connection] (Remoting "<node>:MANAGEMENT" read-1) JBREM000200: Remote connection failed: java.io.IOException: Broken pipe
> 17:11:47,100 ERROR [org.jboss.remoting.remote.connection] (Remoting "<node>:MANAGEMENT" read-1) JBREM000200: Remote connection failed: java.io.IOException: Broken pipe
> this problem only happens sometimes...
> Thanks in advance,
> Br,
> André
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4239) Support Locale.forLanguageTag()
by Romain Pelisse (JIRA)
[ https://issues.jboss.org/browse/WFLY-4239?page=com.atlassian.jira.plugin.... ]
Romain Pelisse commented on WFLY-4239:
--------------------------------------
WFCORE-521 has been merged, so here is the PR: https://github.com/wildfly/wildfly-core/pull/456
> Support Locale.forLanguageTag()
> --------------------------------
>
> Key: WFLY-4239
> URL: https://issues.jboss.org/browse/WFLY-4239
> Project: WildFly
> Issue Type: Feature Request
> Components: Localization
> Affects Versions: 9.0.0.Alpha1
> Environment: JDK 7
> Reporter: Romain Pelisse
> Assignee: Romain Pelisse
> Priority: Minor
>
> The rules for Locale are different in JDK 6 vs 7, and this getLocale() method was written to conform to the JDK 6 rules. Hence it assumes 2 chars for language, 2 chars for country. Beginning with JDK 7 things are much more complex, and we don't support that. The language can be up to 8 chars, country can be [a-zA-Z]{2} | [0-9]{3}, there's the "script" element, and most importantly, Locale.forLanguageTag().
> It would be nice to at least support Locale.forLanguageTag().
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4288) error when trying to execute commands using jboss-cli.sh
by André Caldeira (JIRA)
André Caldeira created WFLY-4288:
------------------------------------
Summary: error when trying to execute commands using jboss-cli.sh
Key: WFLY-4288
URL: https://issues.jboss.org/browse/WFLY-4288
Project: WildFly
Issue Type: Bug
Affects Versions: JBoss AS7 7.2.0.Final
Reporter: André Caldeira
Assignee: Jason Greene
Hi,
I've configured jboss to use ssl, and after this change, sometimes, the command cannot be executed:
[root@<node> ~]# /opt/oss/NSN-SQM-sqm_jboss/install/jboss-eap-6.2/bin/jboss-cli.sh --connect
org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:284)
at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:262)
at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.jboss.modules.Module.run(Module.java:292)
at org.jboss.modules.Main.main(Main.java:455)
Caused by: org.jboss.as.cli.CommandLineException: The controller is not available at localhost:9990
at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:969)
at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:808)
at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:784)
at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:282)
... 8 more
Caused by: java.io.IOException: java.net.ConnectException: JBAS012174: Could not connect to remote://localhost:9990. The connection failed
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:947)
... 11 more
Caused by: java.net.ConnectException: JBAS012174: Could not connect to remote://localhost:9990. The connection failed
at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:129)
at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204)
at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:160)
at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:120)
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
... 13 more
Caused by: java.net.ConnectException: Connection refused
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:739)
at org.xnio.nio.NioXnioWorker$1.handleEvent(NioXnioWorker.java:322)
at org.xnio.nio.NioXnioWorker$1.handleEvent(NioXnioWorker.java:318)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.nio.NioHandle.run(NioHandle.java:90)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:187)
at ...asynchronous invocation...(Unknown Source)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:337)
at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:80)
at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:99)
... 23 more
In server.log what I can see when it happens is:
17:08:30,279 ERROR [org.jboss.remoting.remote.connection] (Remoting "<node>:MANAGEMENT" read-1) JBREM000200: Remote connection failed: java.io.IOException: Broken pipe
17:08:42,071 ERROR [org.jboss.remoting.remote.connection] (Remoting "<node>:MANAGEMENT" read-1) JBREM000200: Remote connection failed: java.io.IOException: Broken pipe
17:11:47,100 ERROR [org.jboss.remoting.remote.connection] (Remoting "<node>:MANAGEMENT" read-1) JBREM000200: Remote connection failed: java.io.IOException: Broken pipe
this problem only happens sometimes...
Thanks in advance,
Br,
André
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (SECURITY-874) CredentialIdentityFactory.NULL_IDENTITY does not get initialized and causes NullPointerExceptions
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/SECURITY-874?page=com.atlassian.jira.plug... ]
Bartosz Baranowski resolved SECURITY-874.
-----------------------------------------
Resolution: Done
Merged on 19/01
> CredentialIdentityFactory.NULL_IDENTITY does not get initialized and causes NullPointerExceptions
> -------------------------------------------------------------------------------------------------
>
> Key: SECURITY-874
> URL: https://issues.jboss.org/browse/SECURITY-874
> Project: PicketBox
> Issue Type: Bug
> Components: Identity
> Affects Versions: PicketBox_4_0_21.Final
> Reporter: Bartosz Baranowski
> Assignee: Bartosz Baranowski
> Attachments: SECURITY-874.patch
>
>
> org.jboss.security.identity.extensions.CredentialIdentityFactory.NULL_IDENTITY does not get initialized to an empty identity due to initialization method returning a reference to NULL_IDENTITY, which has not initialized yet, resulting in null pointer. This causes NullPointerException in org.jboss.security.SecurityContextUtil.clearIdentities() and org.jboss.security.SecurityContextUtil.getIdentities() methods.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4253) CredentialIdentityFactory.NULL_IDENTITY does not get initialized and causes NullPointerExceptions
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-4253?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski commented on WFLY-4253:
------------------------------------------
PB PR has been merged,
> CredentialIdentityFactory.NULL_IDENTITY does not get initialized and causes NullPointerExceptions
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-4253
> URL: https://issues.jboss.org/browse/WFLY-4253
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 8.2.0.Final
> Environment: Java 1.8.0_25
> Reporter: Rostyslav Smirnov
> Assignee: Bartosz Baranowski
>
> org.jboss.security.identity.extensions.CredentialIdentityFactory.NULL_IDENTITY does not get initialized to an empty identity due to initialization method returning a reference to NULL_IDENTITY, which has not initialized yet, resulting in null pointer. This causes NullPointerException in org.jboss.security.SecurityContextUtil.clearIdentities() and org.jboss.security.SecurityContextUtil.getIdentities() methods.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JGRP-1855) FD_HOST: host failure detection protocol
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1855?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-1855:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1113220|https://bugzilla.redhat.com/show_bug.cgi?id=1113220] from VERIFIED to CLOSED
> FD_HOST: host failure detection protocol
> ----------------------------------------
>
> Key: JGRP-1855
> URL: https://issues.jboss.org/browse/JGRP-1855
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4.5, 3.5
>
>
> A new protocol similar to FD_PING which detects entire host failures and suspects all members on the failed host.
> Features are:
> * Contrary to FD_PING which uses a ring structure, FD_HOST will have everyone ping everybody else (similar to FD_ALL)
> ** A structure keeps track of hosts (IP addresses) and members on those hosts
> *** Example
> ||192.168.1.2||192.168.1.3||192.168.1.5||
> |A,B,C|D,E,F|X,Y,Z|
> * We sort the members lexically and the *first* member runs a ping against each other IP address, e.g. A pings 192.168.1.3 and 192.168.1.5, D pings 192.168.1.2 and 192.168.1.5 etc
> * The ping command itself is pluggable and can be a Java class (e.g. using {{InetAddress.isReachable()}}, a script or a command (e.g. {{/sbin/ping}}).
> * When an entire host is suspected, we suspect *all* cluster members on it
> ** Example: if B suspects 192.168.1.5, members X, Y and Z are suspected and removed from the view
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JGRP-1898) FD_HOST many false suspect with Full GC
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1898?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-1898:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1159162|https://bugzilla.redhat.com/show_bug.cgi?id=1159162] from VERIFIED to CLOSED
> FD_HOST many false suspect with Full GC
> ---------------------------------------
>
> Key: JGRP-1898
> URL: https://issues.jboss.org/browse/JGRP-1898
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 3.5.1
> Reporter: Takayoshi Kimura
> Assignee: Takayoshi Kimura
> Fix For: 3.4.7, 3.5.2, 3.6.1
>
> Attachments: FD_HOSTTest.java, test-fdhost.zip
>
>
> Currently FD_HOST PingTask has 2 loops, ping loop and cheking timeout loop.
> {code}
> for (h: hosts) { ping_and_update_timestamp(host) }
> current = System.currentTimeMillis();
> for (h: hosts) { compare current and (ping_timestmp + timeout) }
> {code}
> Testing with large number of hosts, after lengthy Full GC during the ping loop, FD_HOST checks timeout and it counts the Full GC time in, sometimes causes many false suspects.
> For example, 1 min Full GC and 50 sec timeout, all hosts are suspected with current implementation.
> To reduce the impact of the Full GC time, we can combine the 2 loops into 1 loop, ping and checking timeout each host, so the Full GC delay only affects to a single host and never affect to other hosts.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months