[JBoss JIRA] (MODCLUSTER-184) Redeployment of application in Tomcat fails
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-184?page=com.atlassian.jira.pl... ]
Michal Babacek closed MODCLUSTER-184.
-------------------------------------
Closing. Clean-up.
At least one of the following applies:
* the issue has been thoroughly tested as a part of one of the current releases
or
* it hasn't occurred in ~2 years
or
* it's utterly harmless
> Redeployment of application in Tomcat fails
> -------------------------------------------
>
> Key: MODCLUSTER-184
> URL: https://issues.jboss.org/browse/MODCLUSTER-184
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.1.0.Final
> Environment: Windows 7 x64, Java 1.6.0_18-b07 32bit, Tomcat 6.0.29 + APR 1.1.20 + load-demo.war manually unpacked into webapps/ folder.
> Reporter: Ruslan Gainutdinov
> Assignee: Jean-Frederic Clere
>
> Both methods of redeployment cause this error,
> either by pressing reload link in Tomcat manager webapp
> and by touching web.xml in load-demo webapplication.
> Log excerpt:
> 31.08.2010 10:30:41 org.apache.catalina.core.StandardContext reload
> INFO: Reloading this Context has started
> 31.08.2010 10:30:41 org.jboss.modcluster.ModClusterService
> DEBUG: Stop context [/load-demo] in host [localhost]
> 31.08.2010 10:30:41 org.jboss.modcluster.ModClusterService
> DEBUG: Start context [/load-demo] in host [localhost]
> 31.08.2010 10:30:41 org.apache.catalina.core.StandardPipeline registerValve
> INFO: Can't register valve org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve[/load-demo]
> java.lang.NoClassDefFoundError: org/jboss/servlet/http/HttpEvent
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
> at java.lang.Class.privateGetPublicMethods(Class.java:2547)
> at java.lang.Class.getMethods(Class.java:1410)
> at org.apache.tomcat.util.modeler.modules.MbeansDescriptorsIntrospectionSource.createManagedBean(MbeansDescriptorsIntrospectionSource.java:304)
> at org.apache.tomcat.util.modeler.modules.MbeansDescriptorsIntrospectionSource.execute(MbeansDescriptorsIntrospectionSource.java:84)
> at org.apache.tomcat.util.modeler.modules.MbeansDescriptorsIntrospectionSource.loadDescriptors(MbeansDescriptorsIntrospectionSource.java:77)
> at org.apache.tomcat.util.modeler.Registry.load(Registry.java:754)
> at org.apache.tomcat.util.modeler.Registry.loadDescriptors(Registry.java:866)
> at org.apache.tomcat.util.modeler.Registry.findManagedBean(Registry.java:651)
> at org.apache.tomcat.util.modeler.Registry.findManagedBean(Registry.java:963)
> at org.apache.tomcat.util.modeler.Registry.registerComponent(Registry.java:794)
> at org.apache.catalina.core.StandardPipeline.registerValve(StandardPipeline.java:302)
> at org.apache.catalina.core.StandardPipeline.addValve(StandardPipeline.java:448)
> at org.jboss.modcluster.catalina.CatalinaContext.addRequestListener(CatalinaContext.java:114)
> at org.jboss.modcluster.ModClusterService.start(ModClusterService.java:385)
> at org.jboss.modcluster.catalina.CatalinaEventHandlerAdapter.lifecycleEvent(CatalinaEventHandlerAdapter.java:257)
> at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
> at org.apache.catalina.core.StandardContext.start(StandardContext.java:4540)
> at org.apache.catalina.core.StandardContext.reload(StandardContext.java:3391)
> at org.apache.catalina.manager.ManagerServlet.reload(ManagerServlet.java:943)
> at org.apache.catalina.manager.HTMLManagerServlet.reload(HTMLManagerServlet.java:556)
> at org.apache.catalina.manager.HTMLManagerServlet.doGet(HTMLManagerServlet.java:121)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:563)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
> at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:861)
> at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:579)
> at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1584)
> at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.ClassNotFoundException: org.jboss.servlet.http.HttpEvent
> at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
> ... 38 more
> As I can see, it is caused by wrong method signature in class
> org.jboss.modcluster.catalina.CatalinaContext.RequestListenerValve
> public void event(Request request, Response response, HttpEvent event) throws IOException, ServletException
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (MODCLUSTER-155) jboss.mod_cluster.proxyList: invalid hosts cause mod-cluster startup to be delayed
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-155?page=com.atlassian.jira.pl... ]
Michal Babacek closed MODCLUSTER-155.
-------------------------------------
Closing. Clean-up.
At least one of the following applies:
* the issue has been thoroughly tested as a part of one of the current releases
or
* it hasn't occurred in ~2 years
or
* it's utterly harmless
> jboss.mod_cluster.proxyList: invalid hosts cause mod-cluster startup to be delayed
> ----------------------------------------------------------------------------------
>
> Key: MODCLUSTER-155
> URL: https://issues.jboss.org/browse/MODCLUSTER-155
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Bela Ban
> Assignee: Paul Ferraro
> Fix For: 1.1.0.CR2
>
> Attachments: tmp.txt
>
>
> When I set jbss.mod_cluster.proxyList (e.g.) to "http1.dyndns.org:8000,1.2.3.4:8000", mod-cluster does connect to http1.dyndns.org:8000 (assuming it's running), but blocks for 10 minutes trying to connect to 1.2.3.4:8000.
> It eventually times out connecting to 1.2.3.4, and then seems to default to 127.0.0.1 !
> A better mechanism would be to connect via a timeout (see code below), and to simply skip unreachable httpd instances. The reconnect mechanism can always add httpds (which become reachable) later.
> The code to connect to a socket with a timeout would be:
> Socket sock=new Socket(new InetSocketAddress("1.2.3.4", 8000), 1000);
> This call blocks until it has connected to 1.2.3.4:8000, or until 1 sec has elapsed, whichever occurs first.
> In any case, it doesn't block until the OS defined socket connect timeout kicks in; this might be up to 10 mins !
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (MODCLUSTER-206) httpd cores after graceful restart after the mod_cluster configuration is added
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-206?page=com.atlassian.jira.pl... ]
Michal Babacek closed MODCLUSTER-206.
-------------------------------------
Closing. Clean-up.
At least one of the following applies:
* the issue has been thoroughly tested as a part of one of the current releases
or
* it hasn't occurred in ~2 years
or
* it's utterly harmless
> httpd cores after graceful restart after the mod_cluster configuration is added
> -------------------------------------------------------------------------------
>
> Key: MODCLUSTER-206
> URL: https://issues.jboss.org/browse/MODCLUSTER-206
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.0.6, 1.1.0.Final
> Environment: any
> Reporter: Jean-Frederic Clere
> Assignee: Jean-Frederic Clere
> Fix For: 1.0.8, 1.1.1.Final
>
>
> start httpd with mod_cluster configuration.
> add the configuration in httpd.conf
> restart httpd using graceful restart.
> httpd child processes will crash because the storage is not initialized in mod_manager....
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (MODCLUSTER-60) HAModClusterService unnecessary updates DRM each status cycle even if nothing changed
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-60?page=com.atlassian.jira.plu... ]
Michal Babacek closed MODCLUSTER-60.
------------------------------------
Closing. Clean-up.
At least one of the following applies:
* the issue has been thoroughly tested as a part of one of the current releases
or
* it hasn't occurred in ~2 years
or
* it's utterly harmless
> HAModClusterService unnecessary updates DRM each status cycle even if nothing changed
> -------------------------------------------------------------------------------------
>
> Key: MODCLUSTER-60
> URL: https://issues.jboss.org/browse/MODCLUSTER-60
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.0.0.Beta4
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Minor
> Fix For: 1.0.0.CR1
>
>
> When you run with HAModClusterService, every 10 seconds there is logging about a DRM replicantsChanged event and a new HASingletonMaster election. (The election just picks the existing master.) That means the DRM is being updated even when nothing has changed, which shouldn't happen.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (MODCLUSTER-139) Allow override of default clean shutdown behavior
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-139?page=com.atlassian.jira.pl... ]
Michal Babacek closed MODCLUSTER-139.
-------------------------------------
Closing. Clean-up.
At least one of the following applies:
* the issue has been thoroughly tested as a part of one of the current releases
or
* it hasn't occurred in ~2 years
or
* it's utterly harmless
> Allow override of default clean shutdown behavior
> -------------------------------------------------
>
> Key: MODCLUSTER-139
> URL: https://issues.jboss.org/browse/MODCLUSTER-139
> Project: mod_cluster
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 1.1.0.CR1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Minor
> Fix For: 1.1.0.CR3
>
>
> By default, if a web-app is declared <distributable/>, we will only wait until there are no pending requests and all sessions are safely replicated. Only if a web-app is not <distributable/>, do we wait until there are no more active sessions, since there is no session replication. We need the ability to allow the user to override this default behavior, and use session draining even for <distributable/> apps, to avoid overloading remaining servers with failover requests.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (MODCLUSTER-138) Allow configuration of stopContextTimeout units
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-138?page=com.atlassian.jira.pl... ]
Michal Babacek closed MODCLUSTER-138.
-------------------------------------
Closing. Clean-up.
At least one of the following applies:
* the issue has been thoroughly tested as a part of one of the current releases
or
* it hasn't occurred in ~2 years
or
* it's utterly harmless
> Allow configuration of stopContextTimeout units
> -----------------------------------------------
>
> Key: MODCLUSTER-138
> URL: https://issues.jboss.org/browse/MODCLUSTER-138
> Project: mod_cluster
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 1.1.0.CR1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Minor
> Fix For: 1.1.0.CR2
>
>
> Currently, the value specified in stopContextTimeout configuration property is specified in seconds.
> For completions sake, we should add a second property to define the units of this property, with default of TimeUnit.SECONDS.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (MODCLUSTER-223) mod_cluster should issue a warning when Maxcontext is reached and no more context will be taken
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-223?page=com.atlassian.jira.pl... ]
Michal Babacek closed MODCLUSTER-223.
-------------------------------------
Closing. Clean-up.
At least one of the following applies:
* the issue has been thoroughly tested as a part of one of the current releases
or
* it hasn't occurred in ~2 years
or
* it's utterly harmless
> mod_cluster should issue a warning when Maxcontext is reached and no more context will be taken
> -----------------------------------------------------------------------------------------------
>
> Key: MODCLUSTER-223
> URL: https://issues.jboss.org/browse/MODCLUSTER-223
> Project: mod_cluster
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Affects Versions: 1.1.1.Final
> Reporter: Baptiste MATHUS
> Assignee: Jean-Frederic Clere
> Fix For: 1.1.2.Final
>
>
> As a followup to MODCLUSTER-221, I think it would greatly help that httpd issues a warning when the maximum number of configured contexts is reached.
> Thanks a lot!
> PS: maybe this would be even better to also add informations about Max* values when using "AllowDisplay on" parameter.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (MODCLUSTER-242) requests routed to nodes where the context doesn't exist
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-242?page=com.atlassian.jira.pl... ]
Michal Babacek closed MODCLUSTER-242.
-------------------------------------
Closing. Clean-up.
At least one of the following applies:
* the issue has been thoroughly tested as a part of one of the current releases
or
* it hasn't occurred in ~2 years
or
* it's utterly harmless
> requests routed to nodes where the context doesn't exist
> --------------------------------------------------------
>
> Key: MODCLUSTER-242
> URL: https://issues.jboss.org/browse/MODCLUSTER-242
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.0.6
> Reporter: Samuel Mendenhall
> Assignee: Jean-Frederic Clere
> Fix For: 1.0.8
>
>
> Env: 4 JBoss servers w/ mod_cluster sitting behind 2 Apache servers. The 2 Apache servers are proxying to the 4 JBoss servers.
> Those 4 JBoss servers are split into 2 separate clusters, each cluster serving different applications. For example, Cluster1 has AppA and AppB, but Cluster2 has AppC and Appd.
> When attempting to connect to any application through the Apache server, we randomly see 404 errors. Is this because Apache/mod_cluster is trying to route the request to all servers, instead of just the servers with the right web context enabled.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months
[JBoss JIRA] (MODCLUSTER-112) Refactor project into modules for HA, catalina, core, etc.
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-112?page=com.atlassian.jira.pl... ]
Michal Babacek closed MODCLUSTER-112.
-------------------------------------
Closing. Clean-up.
At least one of the following applies:
* the issue has been thoroughly tested as a part of one of the current releases
or
* it hasn't occurred in ~2 years
or
* it's utterly harmless
> Refactor project into modules for HA, catalina, core, etc.
> ----------------------------------------------------------
>
> Key: MODCLUSTER-112
> URL: https://issues.jboss.org/browse/MODCLUSTER-112
> Project: mod_cluster
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 1.2.0.Beta1
>
>
> Restructure maven project to create separate module jars.
> mod-cluster-spi: ContainerEventHandler, Server, Engine, Connector, Host, Context
> mod-cluster-core: ModClusterService and dependencies
> mod-cluster-ha: HAModClusterService and dependencies
> mod-cluster-catalina: ModClusterListener, CatalinaEventHandlerAdapter and spi implementation
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 4 months