[JBoss JIRA] Created: (MODCLUSTER-142) Use UUID for auto-generated jvmRoute
by Paul Ferraro (JIRA)
Use UUID for auto-generated jvmRoute
------------------------------------
Key: MODCLUSTER-142
URL: https://jira.jboss.org/jira/browse/MODCLUSTER-142
Project: mod_cluster
Issue Type: Feature Request
Affects Versions: 1.1.0.CR1
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Fix For: 1.1.0.CR2
Currently, auto-generated jvm-routes are of the form: bind-address:port:engine-name
This exposes internal addresses/ports and is not appropriate for production systems.
To fix that, we can use UUIDs.
e.g.
InetAddress connectorAddress;
int connectorPort;
String engineName;
int addressBytes = connectorAddress.getAddress().length;
int intBytes = Integer.SIZE / Byte.SIZE;
int charBytes = Character.SIZE / Byte.SIZE;
ByteBuffer buffer = ByteBuffer.allocate(addressBytes + intBytes + (engineName.length() * charBytes));
buffer.put(connectorAddress.getAddress());
buffer.putInt(connectorPort);
buffer.asCharBuffer().put(engine);
String jvmRoute = UUID.nameUUIDFromBytes(buffer.array()).toString();
I can think of 2 disadvantages:
1. UUID jvm-routes will be, on average, longer than the current default, i.e. 36 characters as opposed to ~28. Not a significant difference there.
2. For development, exposing the address and port via the jvm route might be useful. To satisfy this requirement, we can make the use of UUIDs configurable.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 7 months
[JBoss JIRA] Created: (MODCLUSTER-144) Affinity replication between multiple mod_cluster servers
by Brett Cave (JIRA)
Affinity replication between multiple mod_cluster servers
---------------------------------------------------------
Key: MODCLUSTER-144
URL: https://jira.jboss.org/jira/browse/MODCLUSTER-144
Project: mod_cluster
Issue Type: Feature Request
Affects Versions: 1.1.0.CR1
Environment: ec2 or centos5.4 + apache2.2
Reporter: Brett Cave
Assignee: Jean-Frederic Clere
mod_cluster maintains affinity (aka session stickiness) between clients and application servers. However, if scaling up or down number of http / frontend servers running mod_cluster, a client may be directed to 1 server intitially and then be directed to another frontend later (depending on connection distribution in front of http servers). If this occurs, other http servers are not aware of each other's affinity, and so there is a chance that (if session is not replicated on jboss as servers) a clients session will be lost if he is migrated to a new http server. This would be particularly applicable in a cluster consisting of a number of buddy partitions fronted by >1 mod_cluster http servers.
Not sure about implmentation, but if the mod_cluster.sar service could report relevant info required to maintain affinity back to all frontend servers, a higher level of fault tolerance could be achieved.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 7 months
[JBoss JIRA] Created: (MODCLUSTER-143) mod_cluster 1.1.0.CR1 doesn't work with Tomcat
by Jean-Frederic Clere (JIRA)
mod_cluster 1.1.0.CR1 doesn't work with Tomcat
----------------------------------------------
Key: MODCLUSTER-143
URL: https://jira.jboss.org/jira/browse/MODCLUSTER-143
Project: mod_cluster
Issue Type: Bug
Affects Versions: 1.1.0.CR1
Environment: 1.1.0.CR1 + Tomcat 6.0.x
Reporter: Jean-Frederic Clere
Assignee: Jean-Frederic Clere
Fix For: 1.1.0.CR2
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 is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 8 months