[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Installing JBoss Messaging clustered
by timfox
I am currently doing a bit of a refactoring, and clustered JBM now runs in the all configuration in JBAS 4.2.0 :)
(It didn't previously work in all in JBoss 4.0.x)
I have removed the cluster node creation from release-admin.xml since the script was very brittle since it relied on text pattern matching to replace stuff, which is very hard to maintain and prone to fail when JBAS config changes without us knowing it.
Now, release-admin.xml simply creates a non clustered config based on another config.
Creating a clustered config can be done very simply as follows:
1) Make sure JBOSS_HOME points to a JBoss-4.2.0.GA installation
2) Create a non clustered config based on "all":
| ant -f release-admin.xml -Dmessaging-config-name=messaging-node0 -Dmessaging-config.source=all
|
3) Ensure the server id in messaging-service.xml is unique (if you have other nodes)
4) replace hsqldb-persistence-service.xml with mysql-clustered-persistence-service.xml
5) Deploy a mysql datasource from jboss-4.2.0.GA/docs/examples/jca
make sure it is binding to DefaultDS
6) Copy the mysql driver into server/messaging-node0/lib
7) If you are running more than config on the same machine use the service binding manager
Uncomment binding manager service from conf/jboss-service.xml
Specifiy the desired ports range e.g. ports-01
in docs/examples/binding-manager/sample-bindings.xml, make sure the jboss messaging config looks like:
| <service-config name="jboss.messaging:service=Connector,transport=bisocket"
| delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
| <delegate-config>
| <attribute name="Configuration"><![CDATA[
| <config>
| <invoker transport="bisocket">
| <attribute name="marshaller" isParam="true">org.jboss.jms.server.remoting.JMSWireFormat</attribute>
| <attribute name="unmarshaller" isParam="true">org.jboss.jms.server.remoting.JMSWireFormat</attribute>
| <attribute name="serializationtype" isParam="true">jms</attribute>
| <attribute name="dataType" isParam="true">jms</attribute>
| <attribute name="socket.check_connection" isParam="true">false</attribute>
| <attribute name="timeout" isParam="true">0</attribute>
| <attribute name="serverBindAddress">${jboss.bind.address}</attribute>
| <attribute name="serverBindPort">4457</attribute>
| <attribute name="leasePeriod">10000</attribute>
| <attribute name="callbackStore">org.jboss.remoting.callback.CallbackStore</attribute>
| <attribute name="clientSocketClass" isParam="true">org.jboss.jms.client.remoting.ClientSocketWrapper</attribute>
| <attribute name="serverSocketClass">org.jboss.jms.server.remoting.ServerSocketWrapper</attribute>
| <attribute name="callbackErrorsAllowed">1</attribute>
| <attribute name="numberOfRetries" isParam="true">1</attribute>
| <attribute name="NumberOfCallRetries" isParam="true">2</attribute>
| <attribute name="clientMaxPoolSize" isParam="true">50</attribute>
| </invoker>
| <handlers>
| <handler subsystem="JMS">org.jboss.jms.server.remoting.JMSServerInvocationHandler</handler>
| </handlers>
| </config>
| ]]></attribute>
| </delegate-config>
| <binding port="4457"/>
| </service-config>
|
| </server>
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4045743#4045743
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4045743
18 years, 10 months
[Design of JBoss/Tomcat Integration] - Commons logging issues
by scott.stark@jboss.org
With the move to commons logging 1.1, there are incompatibilities showing up when users include older configurations that refer to the obsolete Log4jFactory class. The problem is the result of having container classes initialize their logging in the context of the web application class loader. A user facing this problem went through the exercise of statically initializing the Log instance by loading the Log instance of the following classes during the tomcat deployer startup with its class loader established:
| org.apache.jasper.compiler.Compiler
| org.apache.catalina.core.ContainerBase
| org.apache.tomcat.util.digester.Digester
| org.apache.jasper.EmbeddedServletOptions
| org.apache.jasper.compiler.JDTCompiler
| org.apache.jasper.JspCompilationContext
| org.apache.jasper.compiler.JspConfig
| org.apache.jasper.compiler.JspReader
| org.apache.jasper.compiler.JspRuntimeContext
| org.apache.jasper.servlet.JspServlet
| org.apache.jasper.servlet.JspServletWrapper
| org.apache.catalina.session.ManagerBase
| org.apache.jasper.compiler.SmapUtil
| org.apache.catalina.core.StandardContext
| org.apache.catalina.session.StandardManager
| org.apache.jasper.compiler.TldLocationsCache
| org.apache.jasper.xmlparser.UTF8Reader
|
The problem with allowing for lazy initialization in the context of a web app class loader is the use of the TCL logic. Finding web app commons-logging.properties referring to the older older commons logging classes from a LogFactory that has been loaded by the tomcat deployer service class loader is what is causing the problem.
Obfuscating the commons logging classes under an org.jboss.apache.* prefix won't help either as the commons-logging.properties still ends up conflicting. We need to fix the web container logging to the embedding code class loader. The question is whether this is a general change that should be introduced into the tomcat codebase (or jbossweb) rather than something that is done on top.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4045585#4045585
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4045585
18 years, 10 months