[JBoss JIRA] (MODCLUSTER-297) Warnings when compiling mod_cluster
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-297?page=com.atlassian.jira.pl... ]
Michal Babacek closed MODCLUSTER-297.
-------------------------------------
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
> Warnings when compiling mod_cluster
> -----------------------------------
>
> Key: MODCLUSTER-297
> URL: https://issues.jboss.org/browse/MODCLUSTER-297
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.2.1.Beta1
> Reporter: Jean-Frederic Clere
> Assignee: Jean-Frederic Clere
> Priority: Minor
> Fix For: 1.2.1.Final
>
>
> Solaris
> gives the following warning at compile time
> "mod_advertise.c", line 683: warning: implicit function declaration: getpid
> "mod_advertise.c", line 798: warning: argument #5 is incompatible with prototype:
> prototype: pointer to const void : "/tmp/xbroot/ROOT/include/httpd/ap_provider.h", line 50
> argument : pointer to function(pointer to struct request_rec {pointer to struct apr_pool_t {..} pool, pointer to struct conn_rec {..} connection, pointer to struct server_rec {..} server, pointer to struct request_rec {..} next, pointer to struct request_rec {..} prev, pointer to struct request_rec {..} main, pointer to char the_request, int assbackwards, int proxyreq, int header_only, pointer to char protocol, int proto_num, pointer to const char hostname, long request_time, pointer to const char status_line, int status, pointer to const char method, int method_number, long allowed, pointer to struct apr_array_header_t {..} allowed_xmethods, pointer to struct ap_method_list_t {..} allowed_methods, long sent_bodyct, long bytes_sent, long mtime, int chunked, pointer to const char range, long clength, long remaining, long read_length, int read_body, int read_chunked, unsigned int expecting_100, pointer to struct apr_table_t {..} headers_in, pointer to struct apr_table_t {..} headers_out, pointer to struct apr_table_t {..} err_headers_out, pointer to struct apr_table_t {..} subprocess_env, pointer to struct apr_table_t {..} notes, pointer to const char content_type, pointer to const char handler, pointer to const char content_encoding, pointer to struct apr_array_header_t {..} content_languages, pointer to char vlist_validator, pointer to char user, pointer to char ap_auth_type, int no_cache, int no_local_copy, pointer to char unparsed_uri, pointer to char uri, pointer to char filename, pointer to char canonical_filename, pointer to char path_info, pointer to char args, struct apr_finfo_t {..} finfo, struct apr_uri_t {..} parsed_uri, int used_path_info, pointer to struct ap_conf_vector_t {..} per_dir_config, pointer to struct ap_conf_vector_t {..} request_config, pointer to const struct htaccess_result {..} htaccess, pointer to struct ap_filter_t {..} output_filters, pointer to struct ap_filter_t {..} input_filters, pointer to struct ap_filter_t {..} proto_output_filters, pointer to struct ap_filter_t {..} proto_input_filters, int eos_sent}) returning void
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (MODCLUSTER-179) loosing connectivity with jboss on ajp
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-179?page=com.atlassian.jira.pl... ]
Michal Babacek closed MODCLUSTER-179.
-------------------------------------
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
> loosing connectivity with jboss on ajp
> --------------------------------------
>
> Key: MODCLUSTER-179
> URL: https://issues.jboss.org/browse/MODCLUSTER-179
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.0.3.GA
> Environment: Windows server 2008
> Apache 2.2.13 + mod_cluster
> JBoss EAP 5.0.1
> Reporter: Gregory Lardiere
> Assignee: Jean-Frederic Clere
> Labels: nodetimeout
> Fix For: 1.0.3.GA
>
>
> During performance test of a jboss cluster (no session preserved) we issue some problem with mod_cluster, specially when apache try to access to the jboss instance through ajp
> And we don't see where the problem come from (JBoss configuration, mod_cluster configuration, bug).
> We don't use Multicast to discover nodes of the cluster
> [Thu Jul 22 15:13:14 2010] [debug] mod_manager.c(1416): manager_trans STATUS (/)
> [Thu Jul 22 15:13:14 2010] [debug] mod_manager.c(1929): manager_handler STATUS (D:/) processing: "JVMRoute=svayn02a&Load=90"
> [Thu Jul 22 15:13:14 2010] [debug] proxy_util.c(1999): proxy: ajp: has acquired connection for (10.231.242.19)
> [Thu Jul 22 15:13:14 2010] [debug] proxy_util.c(2055): proxy: connecting ajp://10.231.242.19:8009/ to 10.231.242.19:8009
> [Thu Jul 22 15:13:14 2010] [debug] proxy_util.c(2153): proxy: connected ajp://10.231.242.19:8009/ to 10.231.242.19:8009
> [Thu Jul 22 15:13:14 2010] [debug] mod_proxy_cluster.c(1194): ajp_cping_cpong: Done
> [Thu Jul 22 15:13:14 2010] [debug] proxy_util.c(2017): proxy: ajp: has released connection for (10.231.242.19)
> [Thu Jul 22 15:13:14 2010] [debug] mod_manager.c(1970): manager_handler STATUS OK
> [Thu Jul 22 15:13:14 2010] [debug] mod_proxy_cluster.c(943): get_balancer_by_node balancer NOT found
> [Thu Jul 22 15:13:14 2010] [debug] mod_proxy_cluster.c(943): get_balancer_by_node balancer NOT found
> [Thu Jul 22 15:13:14 2010] [debug] mod_proxy_cluster.c(943): get_balancer_by_node balancer NOT found
> [Thu Jul 22 15:13:14 2010] [debug] mod_proxy_cluster.c(943): get_balancer_by_node balancer NOT found
> [Thu Jul 22 15:13:14 2010] [debug] mod_proxy_cluster.c(943): get_balancer_by_node balancer NOT found
> [Thu Jul 22 15:13:14 2010] [debug] mod_proxy_cluster.c(943): get_balancer_by_node balancer NOT found
> [Thu Jul 22 15:13:14 2010] [debug] mod_proxy_cluster.c(943): get_balancer_by_node balancer NOT found
> [Thu Jul 22 15:13:14 2010] [debug] mod_proxy_cluster.c(943): get_balancer_by_node balancer NOT found
> [Thu Jul 22 15:13:14 2010] [debug] mod_manager.c(1416): manager_trans STATUS (/)
> [Thu Jul 22 15:13:14 2010] [debug] mod_manager.c(1929): manager_handler STATUS (D:/) processing: "JVMRoute=svayn01a&Load=90"
> [Thu Jul 22 15:13:14 2010] [debug] proxy_util.c(1999): proxy: ajp: has acquired connection for (10.231.242.18)
> [Thu Jul 22 15:13:14 2010] [debug] proxy_util.c(2055): proxy: connecting ajp://10.231.242.18:8009/ to 10.231.242.18:8009
> [Thu Jul 22 15:13:14 2010] [debug] proxy_util.c(2153): proxy: connected ajp://10.231.242.18:8009/ to 10.231.242.18:8009
> [Thu Jul 22 15:13:14 2010] [debug] mod_proxy_cluster.c(1194): ajp_cping_cpong: Done
> [Thu Jul 22 15:13:14 2010] [debug] proxy_util.c(2017): proxy: ajp: has released connection for (10.231.242.18)
> [Thu Jul 22 15:13:14 2010] [debug] mod_manager.c(1970): manager_handler STATUS OK
> Configuration :
> common.conf :
> LoadModule proxy_module modules/mod_proxy.so
> LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
> LoadModule slotmem_module modules/mod_slotmem.so
> LoadModule manager_module modules/mod_manager.so
> LoadModule proxy_cluster_module modules/mod_proxy_cluster.so
> [...]
> SSLSessionCache none
> MaxRequestsPerChild 5000
> #MaxRequestsPerChild 0
> MaxMemFree 512
> #JkWatchdogInterval 60
> ThreadLimit 300
> ThreadsPerChild 300
> svayn.conf :
> PidFile var/svayn/httpd.pid
> Include conf/common.conf
> Listen 10.231.241.243:8031 http
> #Listen 10.231.241.243:8444 https
> MemManagerFile d:/Apache/var/svayn/manager
> ErrorLog d:/logs/apache/svayn/error.log
> #CustomLog d:/logs/apache/svayn/access.log combined
> NameVirtualHost 10.231.241.243:8031
> #NameVirtualHost 10.231.241.243:8444
> #SSLCertificateFile d:/certs/svayn/cert.crt
> #SSLCertificateKeyFile d:/certs/svayn/cert.key
> <Location />
> <LimitExcept OPTIONS GET HEAD POST PUT DELETE>
> Order deny,allow
> Deny from all
> Allow from wse0846.maafprod.e-corail.com wse0847.maafprod.e-corail.com 127.0.0.1
> </LimitExcept>
> </Location>
> <VirtualHost 10.231.241.243:8031>
> ServerName localhost
> DocumentRoot d:/www/empty
> <Location /cluster-status>
> SetHandler mod_cluster-manager
> Order deny,allow
> Deny from all
> Allow from 10.231.241.243 127.0.0.1
> </Location>
> <Location /server-status>
> SetHandler server-status
> Order deny,allow
> Deny from all
> Allow from 10.231.241.243 127.0.0.1
> </Location>
> </VirtualHost>
> #<VirtualHost 10.231.241.243:8444>
> # ServerName localhost
> # DocumentRoot d:/www/empty
> # SSLEngine on
> #</VirtualHost>
> <VirtualHost 10.231.241.243:8031>
> ServerName nsiperf.maafprod.e-corail.com
> ServerAlias nsiperf
> DocumentRoot d:/www/svayn/
> RewriteEngine on
> RewriteRule ^/(index.asp)?$ /vadautodirectmaaf/SA_ProductionAutoClientDirect_FX/SA_ProductionAutoClientDirect_FX.html?destination=AccesPublicCE&entryPoint=AccesPublicDefaut&enseigne=MAAF&contexte=D4RNMAAF [NC,R=301,L]
> UseAlias 1
> KeepAliveTimeout 60
> MaxKeepAliveRequests 0
> </VirtualHost>
> #<VirtualHost 10.231.241.243:8444>
> # ServerName nsiperf.maafprod.e-corail.com
> # ServerAlias nsiperf
> # DocumentRoot d:/www/svayn/
> # RewriteEngine on
> # RewriteRule ^/(index.asp)?$ /vadautodirectmaaf/SA_ProductionAutoClientDirect_FX/SA_ProductionAutoClientDirect_FX.html?destination=AccesPublicCE&entryPoint=AccesPublicDefaut&enseigne=MAAF&contexte=D4RNMAAF [NC,R=301,L]
> # SSLEngine on
> #</VirtualHost>
> Thx for your help.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (MODCLUSTER-143) mod_cluster 1.1.0.CR1 doesn't work with Tomcat
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-143?page=com.atlassian.jira.pl... ]
Michal Babacek closed MODCLUSTER-143.
-------------------------------------
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 1.1.0.CR1 doesn't work with Tomcat
> ----------------------------------------------
>
> Key: MODCLUSTER-143
> URL: https://issues.jboss.org/browse/MODCLUSTER-143
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.1.0.CR1
> Environment: 1.1.0.CR1 + Tomcat 6.0.x
> Reporter: Jean-Frederic Clere
> Assignee: Paul Ferraro
> Fix For: 1.1.0.CR2
>
> Attachments: patch.txt
>
>
> The following exception is thrown:
> +++
> Apr 6, 2010 4:17:23 PM org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor processChildren
> SEVERE: Exception invoking periodic operation:
> java.lang.ClassCastException: java.lang.String cannot be cast to java.net.InetAddress
> at org.jboss.modcluster.catalina.CatalinaConnector.getAddress(CatalinaConnector.java:53)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPRequestFactory.createConfigRequest(DefaultMCMPRequestFactory.java:62)
> at org.jboss.modcluster.mcmp.impl.ResetRequestSourceImpl.getResetRequests(ResetRequestSourceImpl.java:90)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:413)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:377)
> at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:482)
> at org.jboss.modcluster.catalina.CatalinaEventHandlerAdapter.lifecycleEvent(CatalinaEventHandlerAdapter.java:275)
> at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
> +++
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (MODCLUSTER-91) Connector bind address of 0.0.0.0 propagated to proxy
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-91?page=com.atlassian.jira.plu... ]
Michal Babacek closed MODCLUSTER-91.
------------------------------------
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
> Connector bind address of 0.0.0.0 propagated to proxy
> -----------------------------------------------------
>
> Key: MODCLUSTER-91
> URL: https://issues.jboss.org/browse/MODCLUSTER-91
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.0.1.GA
> Reporter: Brian Stansberry
> Assignee: Paul Ferraro
> Fix For: 1.1.0.Beta1
>
>
> Marek Goldmann wrote:
> > I'm encountered a strange error. When I bind JBoss instance to 0.0.0.0
> > address instead of a fixed ethernet address, node gets registered in
> > mod_cluster, shows in mod_cluster-manager, but every request to
> > registered contexts throws 503 error.
> >
> > httpd error log:
> >
> > [Fri Aug 07 03:21:05 2009] [error] (111)Connection refused: proxy:
> > ajp: attempt to connect to 0.0.0.0:8009 (0.0.0.0) failed
> > [Fri Aug 07 03:21:05 2009] [error] ap_proxy_connect_backend disabling
> > worker for (0.0.0.0)
> > [Fri Aug 07 03:21:15 2009] [error] proxy: ajp: disabled connection for
> > (0.0.0.0)
> > [Fri Aug 07 03:21:25 2009] [error] proxy: ajp: disabled connection for
> > (0.0.0.0)
> >
> > This looks like a bug for me, because many administrators are binding
> > JBoss to 0.0.0.0.
> The java side needs to understand that 0.0.0.0 is useless as a client address and send something useful. Trick is deciding what's useful.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (MODCLUSTER-110) Split ModClusterServiceMBean.ping(String) into 3 methods
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-110?page=com.atlassian.jira.pl... ]
Michal Babacek closed MODCLUSTER-110.
-------------------------------------
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
> Split ModClusterServiceMBean.ping(String) into 3 methods
> --------------------------------------------------------
>
> Key: MODCLUSTER-110
> URL: https://issues.jboss.org/browse/MODCLUSTER-110
> Project: mod_cluster
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Paul Ferraro
> Assignee: Jean-Frederic Clere
> Fix For: 1.1.0.CR1
>
>
> Currently the ModClusterServiceMBean.ping(String) method does 3 things:
> 1. If parameter is null, send a PING command that determines the accessibility/health of each proxy.
> 2. If parameter is not a url, interpret the parameter as a jvm route and send a PING command that determines the accessibility of the node, configured with the specified jvm route, from each proxy.
> 3. If parameter is as a url, interpret the parameter as a url and send a PING command that determines the accessibility of the node (which may or may not be configured in the proxy already) containing a connector matching the protocol, host, and port of the url, from each proxy .
> Rather than 1 multi-purpose function - this method should be split in to 3, corresponding to the 3 functions identified above:
> Map<InetSocketAddress, String> ping();
> Map<InetSocketAddress, String> ping(String jvmRoute);
> Map<InetSocketAddress, String> ping(String protocol, String host, int port);
> or perhaps:
> Map<InetSocketAddress, String> pingProxies();
> Map<InetSocketAddress, String> pingNode(String jvmRoute);
> Map<InetSocketAddress, String> pingConector(String url);
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (MODCLUSTER-260) Move mod_cluster to Git / GitHub
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-260?page=com.atlassian.jira.pl... ]
Michal Babacek closed MODCLUSTER-260.
-------------------------------------
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
> Move mod_cluster to Git / GitHub
> --------------------------------
>
> Key: MODCLUSTER-260
> URL: https://issues.jboss.org/browse/MODCLUSTER-260
> Project: mod_cluster
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 1.0.11, 1.1.3.Final
> Reporter: Radoslav Husar
> Assignee: Jean-Frederic Clere
> Priority: Minor
> Fix For: 1.2.3.Final
>
>
> Sounds like a good idea to move over to GitHub. This will significantly help contribution form the community.
> This will also include creating engineering git repository for prod branches.
> Even projects like JGroups already miraculously moved to github :-)
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months
[JBoss JIRA] (MODCLUSTER-153) ManagerBalancerName doesn't work
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/MODCLUSTER-153?page=com.atlassian.jira.pl... ]
Michal Babacek closed MODCLUSTER-153.
-------------------------------------
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
> ManagerBalancerName doesn't work
> --------------------------------
>
> Key: MODCLUSTER-153
> URL: https://issues.jboss.org/browse/MODCLUSTER-153
> Project: mod_cluster
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.0.3.GA, 1.1.0.CR2
> Environment: any
> Reporter: Jean-Frederic Clere
> Assignee: Jean-Frederic Clere
> Fix For: 1.1.0.CR3
>
>
> mycluster is used whatever value you put in ManagerBalancerName
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 9 months