January 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-3794) Remove all calls to InetAddress.getHostName() (causes reverse DNS lookup)

by Michael Newcomb (JIRA)

Remove all calls to InetAddress.getHostName() (causes reverse DNS lookup) ------------------------------------------------------------------------- Key: JBAS-3794 URL: http://jira.jboss.com/jira/browse/JBAS-3794 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering Affects Versions: JBossAS-4.0.4.GA Environment: Java 5 JBoss 4.0.4 Reporter: Michael Newcomb Assigned To: Brian Stansberry Priority: Minor Any call to InetAddress.getHostName() will cause a reverse DNS lookup. If DNS is not configured properly, can cause slow startup/join times between JBoss clusters. The most notable is in ClusterNode.java: public ClusterNode(IpAddress jgAddress) { if (jgAddress.getAdditionalData() == null) { this.id = jgAddress.getIpAddress().getHostAddress() + ":" + jgAddress.getPort(); } else { this.id = new String(jgAddress.getAdditionalData()); } this.originalJGAddress = jgAddress; StringBuffer sb = new StringBuffer(); java.net.InetAddress jgIPAddr = jgAddress.getIpAddress(); if (jgIPAddr == null) sb.append("<null>"); else { if (jgIPAddr.isMulticastAddress()) sb.append(jgIPAddr.getHostAddress()); else ----->>>> sb.append(getShortName(jgIPAddr.getHostName())); } sb.append(":" + jgAddress.getPort()); this.jgId = sb.toString(); } The following: if (jgIPAddr.isMulticastAddress()) sb.append(jgIPAddr.getHostAddress()); else sb.append(getShortName(jgIPAddr.getHostName())); should be replaced with: sb.append(jgIPAddr.getHostAddress()); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

2
3
0 / 0

[JBoss JIRA] Commented: (JBAS-2004) HTTP session replication: add timeouts for synchronous replication

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2004?page=comments#action_12395859 ] Brian Stansberry commented on JBAS-2004: ---------------------------------------- Is the idea here to not throw an exception if the timeout kicks in, e.g. make a sort of REPL_SEMI_SYNC? Otherwise the existing JBC SyncReplTimeout already does this. > HTTP session replication: add timeouts for synchronous replication > ------------------------------------------------------------------ > > Key: JBAS-2004 > URL: http://jira.jboss.com/jira/browse/JBAS-2004 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Clustering > Reporter: Bela Ban > Assigned To: Brian Stansberry > > SYNC_REPL should be configurable with a timeout. This allows the replication to return after a bounded time, e.g. 500 millisecs, so we don't block on slow cluster members -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-1641) Benchmarking and Load testing http session replication between different settings

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1641?page=all ] Brian Stansberry updated JBAS-1641: ----------------------------------- Fix Version/s: JBossAS-5.0.0.GA (was: JBossAS-5.0.0.Beta4) We've done various flavors of this over time, including recent work for a JBoss World 2008 presentation; final goal here is to use smartfrog to do tests similar to the JBW ones, but targeting AS 5.0.0. > Benchmarking and Load testing http session replication between different settings > --------------------------------------------------------------------------------- > > Key: JBAS-1641 > URL: http://jira.jboss.com/jira/browse/JBAS-1641 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Clustering > Reporter: Ben Wang > Assigned To: Brian Stansberry > Fix For: JBossAS-5.0.0.GA > > Original Estimate: 1 week > Remaining Estimate: 1 week > > We will need load test http session replication using different config settings. > For example, > 1. Syncrhonous vs. asychronous cache mode > 2. Replicationg ranularity: SESSION, ATTRIBUTE, and FIELD > 3. Snapshot manager: instant and periodic -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-5156) Add script to ./bin directory of JBossAS which creates a cluster config

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-5156?page=all ] Brian Stansberry updated JBAS-5156: ----------------------------------- Component/s: Clustering > Add script to ./bin directory of JBossAS which creates a cluster config > ----------------------------------------------------------------------- > > Key: JBAS-5156 > URL: http://jira.jboss.com/jira/browse/JBAS-5156 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Clustering > Reporter: Bela Ban > Assigned To: Brian Stansberry > Priority: Minor > Fix For: JBossAS-5.0.1.CR1 > > > Example: > ./create-cluster-config > This creates node1 and node2 under JBOSS_HOME/server. > The script can be copied from one of the labs in the Clustering training -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-5158) JMS topic bridge to broadcast messages to all nodes in a partition

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-5158?page=all ] Brian Stansberry updated JBAS-5158: ----------------------------------- Component/s: Clustering > JMS topic bridge to broadcast messages to all nodes in a partition > ------------------------------------------------------------------ > > Key: JBAS-5158 > URL: http://jira.jboss.com/jira/browse/JBAS-5158 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Clustering > Environment: JBoss 4.0.2, jboss 1.4.2_06 > Reporter: Ingo Bruell > Assigned To: Brian Stansberry > Attachments: BridgedTopic.java, BridgedTopicMBean.java, jbossmq-bridge-example-service.xml, JMSBridgedTopic.java > > > this bridge receives a message on a topic and delivers this message to all nodes in a partition. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCLUSTER-43) Replace HA-JNDI AutoDiscovery with JGroups

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-43?page=all ] Brian Stansberry updated JBCLUSTER-43: -------------------------------------- Fix Version/s: Backlog > Replace HA-JNDI AutoDiscovery with JGroups > ------------------------------------------ > > Key: JBCLUSTER-43 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-43 > Project: JBoss Clustering > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Bela Ban > Assigned To: Brian Stansberry > Priority: Minor > Fix For: Backlog > > > HA_JNDI AutoDiscovery uses its own IP multicasting-based discovery mechanism. > This is error-prone code and has been the source of many bugs over time. We should replace it with the well-tested JGroups framework, which has a couple of advantages: > - well tested, works > - different discovery mechanisms are available: IP multicast, TCP, GOSSIP etc > - Consolidation of code base -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCLUSTER-112) WL http session repl using JBossCache

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-112?page=all ] Brian Stansberry updated JBCLUSTER-112: --------------------------------------- Fix Version/s: Backlog > WL http session repl using JBossCache > ------------------------------------- > > Key: JBCLUSTER-112 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-112 > Project: JBoss Clustering > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Brian Stansberry > Fix For: Backlog > > > WL http session fine-grained replication using JBossCache > Goal: > To use one single pluggable JBoss web clustering module to run JBoss, Tomcat (standalone), and Weblogic http session replication. Right now, both JBoss and Tomcat standalone has used the same module to perform session replication. Currently, we have options of using different replication granularity: SESSION, ATTRIBUTE, and FIELD where FIELD is the fine-grained replication using TreeCacheAop (aka POJO Cache). What is left is Weblogic one. Although Weblogic has itself a replication layer, use of JBossCache is still attractive because no expensive clustering licensing is needed! > Possible steps need to be done: > 1. Weblogic has an option of allowing a user to specify a session persistence manager (to file, e.g.). This is where other caching solutions used to hook into WL. We should do the same using JBossCache. However, the exact steps need to be determined. > 2. Determine the necessary Manager interface that is needed to unify all 3 solutions. Currently, both in JBoss and Tomcat, we have a notion of Manager and Session interface. Session should be relatively standard. But Manager is Tomcat specific. We will need to investigate on the possibility for extension. > 3. Tomcat uses Valve to create the replication trigger. Need to find a way to do that in WL. How about filter? > 4. Determine the necessary configuration. Currently in JBoss, we allow to have useJK flag for mod_jk specific failover. Solution in WL should work the same. And so is the session replication granularity. > 5. JBossCache startup. Weblogic has a startup class that should allow JBossCache to start up as a singleton and for later lookup. Under JBoss, JBossCache is run as a MBean. > 6. Management attributes. Currently, we are developing JBoss Cache JMX attribute management in 1.3. We will also need to add http session replication management layer as well to be used by all 3 solutions. > 7. Performance benchmarking. When it is completed, we will need to conduct extensive benchmarking. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

1
0
0 / 0

[JBoss JIRA] Moved: (JBAS-5158) JMS topic bridge to broadcast messages to all nodes in a partition

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-5158?page=all ] Brian Stansberry moved JBCLUSTER-63 to JBAS-5158: ------------------------------------------------- Project: JBoss Application Server (was: JBoss Clustering) Key: JBAS-5158 (was: JBCLUSTER-63) Issue Type: Feature Request (was: Patch) > JMS topic bridge to broadcast messages to all nodes in a partition > ------------------------------------------------------------------ > > Key: JBAS-5158 > URL: http://jira.jboss.com/jira/browse/JBAS-5158 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Environment: JBoss 4.0.2, jboss 1.4.2_06 > Reporter: Ingo Bruell > Assigned To: Brian Stansberry > Attachments: BridgedTopic.java, BridgedTopicMBean.java, jbossmq-bridge-example-service.xml, JMSBridgedTopic.java > > > this bridge receives a message on a topic and delivers this message to all nodes in a partition. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCLUSTER-60) Packaging standalone tc5 http session replication using JBossCache

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-60?page=all ] Brian Stansberry updated JBCLUSTER-60: -------------------------------------- Fix Version/s: Backlog > Packaging standalone tc5 http session replication using JBossCache > ------------------------------------------------------------------ > > Key: JBCLUSTER-60 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-60 > Project: JBoss Clustering > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Brian Stansberry > Fix For: Backlog > > Original Estimate: 3 days > Remaining Estimate: 3 days > > Brian will own this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCLUSTER-13) Standalone Tomcat http session replication using JBossCache

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-13?page=all ] Brian Stansberry updated JBCLUSTER-13: -------------------------------------- Fix Version/s: Backlog > Standalone Tomcat http session replication using JBossCache > ----------------------------------------------------------- > > Key: JBCLUSTER-13 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-13 > Project: JBoss Clustering > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Brian Stansberry > Fix For: Backlog > > Original Estimate: 5 weeks > Remaining Estimate: 5 weeks > > Porting the current http session replication implementation to Tomcat standalone. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2008