[JBoss JIRA] (MODCLUSTER-600) Default session draining strategy should perform draining if last cluster member is leaving
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-600?page=com.atlassian.jira.pl... ]
Radoslav Husar updated MODCLUSTER-600:
--------------------------------------
Issue Type: Feature Request (was: Bug)
> Default session draining strategy should perform draining if last cluster member is leaving
> -------------------------------------------------------------------------------------------
>
> Key: MODCLUSTER-600
> URL: https://issues.jboss.org/browse/MODCLUSTER-600
> Project: mod_cluster
> Issue Type: Feature Request
> Components: Core & Container Integration (Java)
> Affects Versions: 1.3.7.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> Currently, the default session draining strategy consults implementation of org.jboss.modcluster.container.Context#isDistributable for whether session draining is enabled org.jboss.modcluster.config.impl.SessionDrainingStrategyEnum#isEnabled. In fact the method consulted should be checking for whether data is available on other nodes; since if the last member is leaving a data loss will occur.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 8 months
[JBoss JIRA] (MODCLUSTER-467) ExcludedContexts are ignored if modcluster subsystem initialize before default-host
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-467?page=com.atlassian.jira.pl... ]
Radoslav Husar closed MODCLUSTER-467.
-------------------------------------
Assignee: Radoslav Husar (was: Jean-Frederic Clere)
Resolution: Duplicate Issue
Labels: (was: jboss)
This is a duplicate of MODCLUSTER-566 and the related integration issues (WFLY-6863) – if this is not the case, please reopen.
> ExcludedContexts are ignored if modcluster subsystem initialize before default-host
> -----------------------------------------------------------------------------------
>
> Key: MODCLUSTER-467
> URL: https://issues.jboss.org/browse/MODCLUSTER-467
> Project: mod_cluster
> Issue Type: Bug
> Components: Core & Container Integration (Java)
> Affects Versions: 1.2.11.Final
> Reporter: Pierre-Luc Gregoire
> Assignee: Radoslav Husar
> Attachments: MODCLUSTER-467-patch.diff
>
>
> With JBoss 7.2.0.Final, modcluster will ignore excludedContexts defined in modcluster subsystem (ie jmx-console, ROOT). This is caused by engine.getHosts() not yet available when org.jboss.modcluster.ModClusterService.init(Server) try to setup his list of excludedContexts.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 8 months
[JBoss JIRA] (MODCLUSTER-638) Mod_cluster listener doesn't start: misleading docs
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-638?page=com.atlassian.jira.pl... ]
Radoslav Husar updated MODCLUSTER-638:
--------------------------------------
Component/s: Documentation & Demos
> Mod_cluster listener doesn't start: misleading docs
> ---------------------------------------------------
>
> Key: MODCLUSTER-638
> URL: https://issues.jboss.org/browse/MODCLUSTER-638
> Project: mod_cluster
> Issue Type: Bug
> Components: Core & Container Integration (Java), Documentation & Demos
> Affects Versions: 2.0.0.Alpha1
> Environment: Tomcat 9.0.2, Windows, Oracle JDK 8
> Reporter: Michal Karm Babacek
> Assignee: Radoslav Husar
> Priority: Blocker
> Labels: ux
> Fix For: 2.0.0.Alpha1
>
>
> h3. Old listener conf from docs fails to start, automagic elimination aftermath
> h4. server.xml
> {code}
> <Listener className="org.jboss.modcluster.container.catalina.standalone.ModClusterListener" connectorPort="8009"/>
> {code}
> h4. Fails to start Tomcat server
> {code}
> INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version: Apache Tomcat/9.0.2
> INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server built: Nov 25 2017 21:08:02 UTC
> INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server number: 9.0.2.0
> INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Name: Windows NT (unknown)
> INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Version: 10.0
> INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Architecture: amd64
> INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Java Home: C:\Program Files\jdk1.8.0_last\jre
> INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Version: 1.8.0_121-b13
> INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor: Oracle Corporation
> INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE: C:\apache-tomcat-9.0.2-windows-x64\apache-tomcat-9.0.2
> INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME: C:\apache-tomcat-9.0.2-windows-x64\apache-tomcat-9.0.2
> INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.config.file=C:\apache-tomcat-9.0.2-windows-x64\apache-tomcat-9.0.2\conf\logging.properties
> INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
> INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djdk.tls.ephemeralDHKeySize=2048
> INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.protocol.handler.pkgs=org.apache.catalina.webresources
> INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dignore.endorsed.dirs=
> INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dcatalina.base=C:\apache-tomcat-9.0.2-windows-x64\apache-tomcat-9.0.2
> INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dcatalina.home=C:\apache-tomcat-9.0.2-windows-x64\apache-tomcat-9.0.2
> INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.io.tmpdir=C:\apache-tomcat-9.0.2-windows-x64\apache-tomcat-9.0.2\temp
> INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded APR based Apache Tomcat Native library [1.2.16] using APR version [1.6.3].
> INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true].
> INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR/OpenSSL configuration: useAprConnector [false], useOpenSSL [true]
> INFO [main] org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL successfully initialized [OpenSSL 1.0.2m 2 Nov 2017]
> INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["http-nio-8080"]
> INFO [main] org.apache.tomcat.util.net.NioSelectorPool.getSharedSelector Using a shared selector for servlet write/read
> INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["ajp-nio-8009"]
> INFO [main] org.apache.tomcat.util.net.NioSelectorPool.getSharedSelector Using a shared selector for servlet write/read
> INFO [main] org.jboss.modcluster.ModClusterService.init MODCLUSTER000001: Initializing mod_cluster version 2.0.0.Alpha1-SNAPSHOT
> SEVERE [main] org.apache.catalina.startup.Catalina.load Catalina.start
> org.apache.catalina.LifecycleException: Failed to initialize component [StandardServer[8005]]
> at org.apache.catalina.util.LifecycleBase.handleSubClassException(LifecycleBase.java:441)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:139)
> at org.apache.catalina.startup.Catalina.load(Catalina.java:622)
> at org.apache.catalina.startup.Catalina.load(Catalina.java:645)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:309)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:492)
> Caused by: java.lang.RuntimeException: MODCLUSTER000valid advertise interface configured! Disabling multicast advertise mechanism.
> at org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl.initializeDatagramChannel(AdvertiseListenerImpl.java:133)
> at org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl.start(AdvertiseListenerImpl.java:140)
> at org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl.<init>(AdvertiseListenerImpl.java:102)
> at org.jboss.modcluster.advertise.impl.AdvertiseListenerFactoryImpl.createListener(AdvertiseListenerFactoryImpl.java:38)
> at org.jboss.modcluster.ModClusterService.init(ModClusterService.java:163)
> at org.jboss.modcluster.container.tomcat.TomcatEventHandlerAdapter.init(TomcatEventHandlerAdapter.java:249)
> at org.jboss.modcluster.container.tomcat.TomcatEventHandlerAdapter.lifecycleEvent(TomcatEventHandlerAdapter.java:187)
> at org.jboss.modcluster.container.tomcat.ModClusterListener.lifecycleEvent(ModClusterListener.java:118)
> at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
> at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:424)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:137)
> ... 8 more
> INFO [main] org.apache.catalina.startup.Catalina.load Initialization processed in 1724 ms
> SEVERE [main] org.apache.catalina.startup.Catalina.start The required Server component failed to start so Tomcat is unable to start.
> org.apache.catalina.LifecycleException: An invalid Lifecycle transition was attempted ([before_stop]) for component [StandardService[Catalina]] in state [INITIALIZED]
> at org.apache.catalina.util.LifecycleBase.invalidTransition(LifecycleBase.java:431)
> at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:244)
> at org.apache.catalina.core.StandardServer.stopInternal(StandardServer.java:791)
> at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:257)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:175)
> at org.apache.catalina.startup.Catalina.start(Catalina.java:671)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:353)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:493)
> WARNING [main] org.apache.catalina.util.LifecycleBase.destroy Calling stop() on failed component [StandardServer[80trigger clean-up did not complete.
> org.apache.catalina.LifecycleException: An invalid Lifecycle transition was attempted ([before_stop]) for component [StandardService[Catalina]] in state [INITIALIZED]
> at org.apache.catalina.util.LifecycleBase.invalidTransition(LifecycleBase.java:431)
> at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:244)
> at org.apache.catalina.core.StandardServer.stopInternal(StandardServer.java:791)
> at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:257)
> at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:293)
> at org.apache.catalina.startup.Catalina.start(Catalina.java:675)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:353)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:493)
> INFO [main] org.jboss.modcluster.ModClusterService.shutdown MODCLUSTER000002: Initiating mod_cluster shutdown
> INFO [main] org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler ["http-nio-8080"]
> INFO [main] org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler ["ajp-nio-8009"]
> {code}
> h2. Call to action
> Please, fix the docs:
> * [README.md|https://github.com/modcluster/mod_cluster/blame/7e7dcbfef3bd357...]
> * [Documentation|https://github.com/modcluster/modcluster.io/blame/master/do...]
> To save you some attributes lookup and copy pasting, you might want to take a look at this [complete list|https://github.com/Karm/jws-3-tomcat-8-mod_cluster/blob/master/serve...].
> I guess at least this should find its way into the docs, give or take:
> {code}
> <Listener className="org.jboss.modcluster.container.catalina.standalone.ModClusterListener"
> advertise="true"
> advertiseInterface="172.16.27.10"
> advertiseGroupAddress="224.0.1.105"
> advertisePort="23364"
> connectorPort="8009"
> />
> {code} plus the message in the log must be improved. A random user has no chance to understand what the listener wants - it just looks as if it disabled advertising:{code} java.lang.RuntimeException: MODCLUSTER000valid advertise interface configured! Disabling multicast advertise mechanism.{code}, while in fact the whole Tomcat goes down.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 8 months
[JBoss JIRA] (MODCLUSTER-538) A proper man page instead of Readme file and Selinux policy file in Fedora
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-538?page=com.atlassian.jira.pl... ]
Radoslav Husar updated MODCLUSTER-538:
--------------------------------------
Component/s: (was: Core & Container Integration (Java))
> A proper man page instead of Readme file and Selinux policy file in Fedora
> --------------------------------------------------------------------------
>
> Key: MODCLUSTER-538
> URL: https://issues.jboss.org/browse/MODCLUSTER-538
> Project: mod_cluster
> Issue Type: Enhancement
> Components: Native (httpd modules)
> Affects Versions: 1.3.3.Final
> Environment: Fedora 24, Fedora 25, Fedora Rawhide
> Reporter: Michal Karm Babacek
> Assignee: Michal Karm Babacek
> Priority: Minor
>
> Current doc in the RPM distribution is a Markdown file {{/usr/share/doc/mod_cluster/README}}. SELinux must be configured manually according to documentation in {{/etc/httpd/conf.d/mod_cluster.conf}}. It would be much better if user has the SELinux policy set during installation via loading a policy file and it would be also great if typing {{man mod_cluster}} actually brought up a proper man page.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 8 months
[JBoss JIRA] (MODCLUSTER-653) mod_cluster DefaultMCMPHandler should handle "Connection: close" response header and close a connection
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-653?page=com.atlassian.jira.pl... ]
Radoslav Husar updated MODCLUSTER-653:
--------------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
Merged, thanks for the fix [~mmiura]!
> mod_cluster DefaultMCMPHandler should handle "Connection: close" response header and close a connection
> -------------------------------------------------------------------------------------------------------
>
> Key: MODCLUSTER-653
> URL: https://issues.jboss.org/browse/MODCLUSTER-653
> Project: mod_cluster
> Issue Type: Bug
> Components: Core & Container Integration (Java)
> Affects Versions: 1.3.7.Final
> Reporter: Masafumi Miura
> Assignee: Radoslav Husar
> Fix For: 1.4.0.Final, 2.0.0.Alpha1, 1.3.10.Final
>
>
> mod_cluster {{DefaultMCMPHandler#sendRequest()}} does not close a connection when Apache httpd closes a connection and responds to MCMP STATUS request with "{{Connection: close}}" response header. (As {{KeepAlive Off}} is set by default, Apache httpd closes a connection and responds to MCMP STATUS request with "{{Connection: close}}".) Therefore, CLOSE_WAIT connection remains every MCMP STATUS command.
> This CLOSE_WAIT connection will be cleaned when trying to send the next MCMP STATUS request, so there's no functional impact. And this is not a critical issue as neither connection leak nor file descriptor leak happens. However, it's better that mod_cluster handles the "{{Connection: close}}" response header and close a connection.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 8 months
[JBoss JIRA] (MODCLUSTER-460) Silence superflous "MODCLUSTER000033: Failed to interrupt socket reception" on shutdown
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-460?page=com.atlassian.jira.pl... ]
Radoslav Husar updated MODCLUSTER-460:
--------------------------------------
Summary: Silence superflous "MODCLUSTER000033: Failed to interrupt socket reception" on shutdown (was: Silence superflous "MODCLUSTER000033: Failed to interrupt socket reception" on shutdown (specific to macOS))
> Silence superflous "MODCLUSTER000033: Failed to interrupt socket reception" on shutdown
> ---------------------------------------------------------------------------------------
>
> Key: MODCLUSTER-460
> URL: https://issues.jboss.org/browse/MODCLUSTER-460
> Project: mod_cluster
> Issue Type: Bug
> Components: Core & Container Integration (Java)
> Affects Versions: 1.3.1.Final
> Environment: macOS
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
> Fix For: 2.0.0.Alpha1
>
>
> This seems to be caused by the legacy code in mod_cluster, which could instead make use of interruptible channels introduced since JDK 1.4. Simpler option would be log this message onto debug.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 8 months