I want to run two deployed applications ( .ear ) in two instances of JBoss 6.0 at the same time
I have changed all used ports of both standalone.xml files including http , management-http , etc...
Like this:
application1.ear : socket-binding name="http" port="8080
application2.ear : socket-binding name="http" port="8081
application1.ear : name="management-http" port="9990
application2.ear : name="management-http" port="9991
Any Help is appreciated
Following are the two ways to run mutliple JBoss instance on same server.
Bind each instance to a different IP address
This is the easiest and most recommended way to solve this problem. If the server has multiple NICs then this is simple. If not, then one must "multi-home" the server. In other words, assign the server more than one IP address through OS configuration. Start the instances like so:
$JBOSS_HOME1/bin/run.sh -b <ip-addr-1>
$JBOSS_HOME2/bin/run.sh -b <ip-addr-2>
The same $JBOSS_HOME can be used with multiple "profiles" in $JBOSS_HOME/server. For example:
$JBOSS_HOME/bin/run.sh -b <ip-addr-1> -c node1
$JBOSS_HOME/bin/run.sh -b <ip-addr-2> -c node2
Service Binding Manager
Configure the "Service Binding Manager" to tell the JBoss instances which ports to use.
Uncomment the "jboss.system:service=ServiceBindingManager" MBean in $JBOSS_HOME/server/$PROFILE/conf/jboss-service.xml.
<mbean code="org.jboss.services.binding.ServiceBindingManager"
name="jboss.system:service=ServiceBindingManager">
<attribute name="ServerName">ports-01</attribute>
<attribute name="StoreURL">${jboss.home.url}/docs/examples/binding-manager/sample-bindings.xml</attribute>
<attribute name="StoreFactoryClassName">
org.jboss.services.binding.XMLServicesStoreFactory
</attribute>
</mbean>
This tells JBoss to use the port numbering scheme defined by "ports-01" in $JBOSS_HOME/docs/examples/binding-manager/sample-bindings.xml. This scheme increases the second most significant digit of every port by 100. For example, the JNDI port is 1099 by default but 1199 using the ports-01 scheme; the HTTP port is 8080 by default but 8180 using the ports-01 scheme. The sample-bindings.xml file contains 4 port schemes:
ports-default
ports-01
ports-02
ports-03
You may want to configure the port set used at start up from the command line or through a system property. If so, adjust the MBean's ServerName to refer to a system property, for example:
<mbean code="org.jboss.services.binding.ServiceBindingManager"
name="jboss.system:service=ServiceBindingManager">
<attribute name="ServerName">${jboss.service.binding.set:ports-default}</attribute>
<attribute name="StoreURL">${jboss.home.url}/docs/examples/binding-manager/sample-bindings.xml</attribute>
<attribute name="StoreFactoryClassName">
org.jboss.services.binding.XMLServicesStoreFactory
</attribute>
</mbean>
Now change it through the following property directly on run.sh/run.bat or add it to your run.conf options:
-Djboss.service.binding.set=ports-01
If you need more than 4 port sets defined in sample-bindings.xml by default, please refer to the following article for JBOSS 6 EAP:
https://access.redhat.com/site/solutions/237933
Related
What configuration files/values to change in order to run second instance of the JBoss Fuse on the same box?
Second instance properties after configuration:
Installation home: c:\jboss-fuse-6.2.1.redhat-084-2 (/usr/app/jboss-fuse-6.2.1.redhat-084-2)
Remote debug port: 5006
Jetty/CXF port: 8282
RMI registry port: 2099
RMI server port: 54444
SSH port: 8202
ActiveMQ port: 62616
HawtIO console: http://localhost:8282/hawtio/login
Installation home:
$JBOSS_FUSE_HOME\bin\setenv
----
KARAF_HOME=/usr/app/jboss-fuse-6.2.1.redhat-084-2
KARAF_DATA=/usr/app/jboss-fuse-6.2.1.redhat-084-2/data
KARAF_ETC=/usr/app/jboss-fuse-6.2.1.redhat-084-2/etc
export KARAF_HOME
export KARAF_DATA
export KARAF_ETC
%JBOSS_FUSE_HOME%\bin\setenv.bat
----
SET KARAF_HOME=c:\jboss-fuse-6.2.1.redhat-084-2
SET KARAF_DATA=c:\jboss-fuse-6.2.1.redhat-084-2\data
SET KARAF_ETC=c:\jboss-fuse-6.2.1.redhat-084-2\etc
Remote debug port
$JBOSS_FUSE_HOME\bin\admin
$JBOSS_FUSE_HOME\bin\karaf
$JBOSS_FUSE_HOME\bin\patch
----
DEFAULT_JAVA_DEBUG_OPTS="-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5006"
%JBOSS_FUSE_HOME%\bin\admin.bat
%JBOSS_FUSE_HOME%\bin\karaf.bat
%JBOSS_FUSE_HOME%\bin\patch.bat
----
set DEFAULT_JAVA_DEBUG_OPTS=-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5006
Jetty/CXF port
JBOSS_FUSE_HOME\etc\jetty.xml
---
<Property name="jetty.port" default="8282"/>
JBOSS_FUSE_HOME\etc\org.ops4j.pax.web.cfg
---
org.osgi.service.http.port=8282
JBOSS_FUSE_HOME\etc\system.properties
---
org.osgi.service.http.port=8282
RMI registry port/RMI server port
JBOSS_FUSE_HOME\etc\org.apache.karaf.management.cfg
---
rmiRegistryPort = 2099
rmiServerPort = 54444
SSH port
JBOSS_FUSE_HOME\etc\org.apache.karaf.shell.cfg
---
sshPort = 8202
ActiveMQ port
JBOSS_FUSE_HOME\etc\system.properties
---
activemq.port = 62616
activemq.host = localhost
This depends on the applications installed, so let's stick with vanilla JBoss Fuse 6.2+
There are 3 components that need a change in configuration:
ActiveMQ broker
Hawtio web interface
sshd
Conflicts happen while binding on TCP/IP ports. Use two sets of ports and you're done.
Configuration files are located in $KARAF_ETC folder, usually etc/ inside JBoss Fuse installation folder.
ActiveMQ
Change property activemq.port inside etc/system.properties.
Default value is 61616.
Hawtio / OSGi HTTP
Change property org.osgi.service.http.port inside etc/system.properties. Default is 8181.
This is also defined in etc/org.ops4j.pax.web.cfg.
SSH
Change property sshPort inside etc/org.apache.karaf.shell.cfg. Default is 8101
Another way: Create a Fabric with two child containers. Each container is just like a regular instance. The infrastructure is just a bit more complex than the standalone one.
I'm in the process of configuring a HA Wildfly cluster for session replication and I'm having trouble figuring out how to add JVM arguments to the individual servers in the domain. The arguments I add in domain.conf are applied to the process controller but not the individual servers. I can change the heap size for the server groups in domain.xml:
but I'm having trouble adding other arguments. Can I use this jvm section to add any argument? Is there another way to add arguments to server groups? Thanks.
You can use the jvm-options attribute on in CLI or you really want to edit the XML you can use <jvm-options/>.
CLI Example:
/server-group=main-server-group/jvm=default:write-attribute(name=jvm-options, value=["-XX:-HeapDumpOnOutOfMemoryError", "-XX:+UseCompressedOops"])
XML Example:
<server-group name="main-server-group" profile="full">
<jvm name="default">
<heap size="64m" max-size="512m"/>
<jvm-options>
<option value="-XX:-HeapDumpOnOutOfMemoryError"/>
<option value="-XX:+UseCompressedOops"/>
</jvm-options>
</jvm>
<socket-binding-group ref="full-sockets"/>
</server-group>
You can also define them at the server level if you need some setting only on a single server in the server group. See the host.xml for an example of that.
We are currently testing to move from Wildfly 8.2.0 to Wildfly 9.0.0.CR1 (or CR2 built from snapshot). The system is a cluster using mod_cluster and is running on VPS what in fact prevents it from using multicast.
On 8.2.0 we have been using the following configuration of the modcluster that works well:
<mod-cluster-config proxy-list="1.2.3.4:10001,1.2.3.5:10001" advertise="false" connector="ajp">
<dynamic-load-provider>
<load-metric type="cpu"/>
</dynamic-load-provider>
</mod-cluster-config>
Unfortunately, on 9.0.0 proxy-list was deprecated and the start of the server will finish with an error. There is a terrible lack of documentation, however after a couple of tries I have discovered that proxy-list was replaced with proxies that are a list of outbound-socket-bindings. Hence, the configuration looks like the following:
<mod-cluster-config proxies="mc-prox1 mc-prox2" advertise="false" connector="ajp">
<dynamic-load-provider>
<load-metric type="cpu"/>
</dynamic-load-provider>
</mod-cluster-config>
And the following should be added into the appropriate socket-binding-group (full-ha in my case):
<outbound-socket-binding name="mc-prox1">
<remote-destination host="1.2.3.4" port="10001"/>
</outbound-socket-binding>
<outbound-socket-binding name="mc-prox2">
<remote-destination host="1.2.3.5" port="10001"/>
</outbound-socket-binding>
So far so good. After this, the httpd cluster starts registering the nodes. However I am getting errors from load balancer. When I look into /mod_cluster-manager, I see a couple of Node REMOVED lines and there are also many many errors like:
ERROR [org.jboss.modcluster] (UndertowEventHandlerAdapter - 1) MODCLUSTER000042: Error MEM sending STATUS command to node1/1.2.3.4:10001, configuration will be reset: MEM: Can't read node
In the log of mod_cluster there are the equivalent warnings:
manager_handler STATUS error: MEM: Can't read node
As far as I understand, the problem is that although wildfly/modcluster is able to connect to httpd/mod_cluster, it does not work the other way. Unfortunately, even after an extensive effort I am stuck.
Could someone help with setting mod_cluster for Wildfly 9.0.0 without advertising? Thanks a lot.
I ran into the Node Removed issue to.
I managed to solve it by using the following as instance-id
<subsystem xmlns="urn:jboss:domain:undertow:2.0" instance-id="${jboss.server.name}">
I hope this will help someone else to ;)
There is no need for any unnecessary effort or uneasiness about static proxy configuration. Each WildFly distribution comes with xsd sheets that describe xml subsystem configuration. For instance, with WildFly 9x, it's:
WILDFLY_DIRECTORY/docs/schema/jboss-as-mod-cluster_2_0.xsd
It says:
<xs:attribute name="proxies" use="optional">
<xs:annotation>
<xs:documentation>List of proxies for mod_cluster to register with defined by outbound-socket-binding in socket-binding-group.</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:list itemType="xs:string"/>
</xs:simpleType>
</xs:attribute>
The following setup works out of box
Download wildfly-9.0.0.CR1.zip or build with ./build.sh from sources
Let's assume you have 2 boxes, Apache HTTP Server with mod_cluster acting as a load balancing proxy and your WildFly server acting as a worker. Make sure botch servers can access each other on both MCMP enabled VirtualHost's address and port (Apache HTTP Server side) and on WildFly AJP and HTTP connector side. The common mistake is to binf WildFLy to localhost; it then reports its addess as localhost to the Apache HTTP Server residing on a dofferent box, which makes it impossible for it to contact WildFly server back. The communication is bidirectional.
This is my configuration diff from the default wildfly-9.0.0.CR1.zip.
328c328
< <mod-cluster-config advertise-socket="modcluster" connector="ajp" advertise="false" proxies="my-proxy-one">
---
> <mod-cluster-config advertise-socket="modcluster" connector="ajp">
384c384
< <subsystem xmlns="urn:jboss:domain:undertow:2.0" instance-id="worker-1">
---
> <subsystem xmlns="urn:jboss:domain:undertow:2.0">
435c435
< <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:102}">
---
> <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
452,454d451
< <outbound-socket-binding name="my-proxy-one">
< <remote-destination host="10.10.2.4" port="6666"/>
< </outbound-socket-binding>
456c453
< </server>
---
> </server>
Changes explanation
proxies="my-proxy-one", outbound socket binding name; could be more of them here.
instance-id="worker-1", the name of the worker, a.k.a. JVMRoute.
offset -- you could ignore, it's just for my test setup. Offset does not apply to outbound socket bindings.
<outbound-socket-binding name="my-proxy-one"> - IP and port of the VirtualHost in Apache HTTP Server containing EnableMCPMReceive directive.
Conclusion
Generally, these MEM read / node error messages are related to network problems, e.g. WildFly can contact Apache, but Apache cannot contact WildFly back. Last but not least, it could happen that the Apache HTTP Server's configuration uses PersistSlots directive and some substantial enviroment conf change took place, e.g. switch from mpm_prefork to mpm_worker. In this case, MEM Read error messages are not realted to WildFly, but to the cached slotmem files in HTTPD/cache/mod_custer that need to be deleted.
I'm certain it's network in your case though.
After a couple of weeks I got back to the problem and found the solution. The problem was - of course - in configuration and had nothing in common with the particular version of Wildfly. Mode specifically:
There were three nodes in the domain and three servers in each node. All nodes were launched with the following property:
-Djboss.node.name=nodeX
...where nodeX is the name of a particular node. However, it meant that all three servers in the node get the same name, which is exactly what confused the load balancer.
As soon as I have removed this property, everything started to work.
There are two scenarios as mentioned below.
First Scenario:
Node1: 192.168.69.201
Node2: 192.168.69.202
Second Scenario:
Node1: 192.168.69.201
Node2: 192.168.68.203
Cluster is formed successfully in the first scenario but not in the second one. I used TCP protocol as mentioned in the below xml:
<config xmlns="urn:org:jgroups"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:org:jgroups file:schema/JGroups-3.2.xsd">
<TCP
bind_addr="${jgroups.tcp.address:192.168.68.201}"
bind_port="${jgroups.tcp.port:7800}"
loopback="true"
...
/>
<MPING bind_addr="${jgroups.bind_addr:192.168.68.201}" break_on_coord_rsp="true"
mcast_addr="${jgroups.mping.mcast_addr:228.2.4.6}"
mcast_port="${jgroups.mping.mcast_port:43366}"
ip_ttl="${jgroups.udp.ip_ttl:2}"
num_initial_members="3"/>
...
...
</config>
192.168.68.201 was replaced by respective IP address at a particular node.
Most likely, multicast traffic is not allow to travel between 192.168.69.x and 192.168.68.x networks which is a common problem when using multicast based PING protocols (MPING). Either, talk to your network guys to allow multicast between those two subnets, or as suggested by Arjun, try using TCPPING specifying the IP addresses of the nodes to connect to. Here's an example of TCPPING configuration.
Try using TCPPING instead of MPING
I am setting up CruiseControl.NET and I get the following error message on the webdashboard:
No connection could be made because the target machine actively refused it 127.0.0.1:21234
The Url it is looking for is: tcp://localhost:21234/CruiseManager.rem
However the ccnet website in IIS has its tcp port set to 82.
So I use the following Url to navigate to the webdashboard http://127.0.0.1:82/ccnet/ViewFarmReport.aspx
I tried changing the Tcp port in IIS to 21234 and I get the following error message on the webdashboard:
Tcp channel protocol violation: expecting preamble.
I have also tried opening the port with the following command:
netsh firewall add portopening TCP 21234 CCNET
When I try and start the CCNET service I get the following message
The CruiseControl.NET Server service started then stopped. Some services stop automatically if they have no work to do....
Can anyone help me with this problem please?
EDIT - Adding config file
<cruisecontrol xmlns:cb="urn:ccnet.config.builder">
<cb:define PublishDir="C:\Deploy\Portal2.0Build"/>
<project name="Portal2.0">
<workingDirectory>C:\PortalCruiseControl\Working</workingDirectory>
<artifactDirectory>C:\PortalCruiseControl\Artifacts</artifactDirectory>
<webURL>http://192.168.17.59:82/ccnet</webURL>
<triggers>
<intervalTrigger name="continuous" seconds="10"
buildCondition="IfModificationExists"/>
</triggers>
<sourcecontrol type="svn">
<trunkUrl>https://portal2003.local:8443/svn/portalv2.0/trunk</trunkUrl>
<executable>C:\Program Files (x86)\VisualSVN Server\bin\svn.exe</executable>
<username>ccnet</username>
<password>***</password>
<cleanCopy>true</cleanCopy>
</sourcecontrol>
<tasks>
<msbuild>
<executable>
C:\WINDOWS\microsoft.net\Framework64\v3.5\MSBuild.exe
</executable>
<projectFile>Portal2.0.sln</projectFile>
<buildArgs>
/target:build;publish /p:Configuration=Release /p:MSBuildExtensionsPath=C:\Progra~2\MSBuild /p:MSBuildEmitSolution=1 /p:publishdir=C:\Deploy\Portal2.0Build /verbosity:diag
</buildArgs>
<logger>
C:\Program Files (x86)\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MSBuild.dll
</logger>
</msbuild>
</tasks>
<labeller type="assemblyVersionLabeller">
<major>2</major>
<minor>0</minor>
<incrementOnFailure>false</incrementOnFailure>
</labeller>
<publishers>
<statistics />
<xmllogger />
<package>
<name>ZipFilePublish</name>
<compression>9</compression>
<always>false</always>
<flatten>false</flatten>
<baseDirectory>$(PublishDir)</baseDirectory>
<dynamicValues>
<replacementValue property="name">
<format>C:\Deploy\Builds\PortalBuild{0}.zip</format>
<parameters>
<namedValue name="$CCNetLabel" value="Default" />
</parameters>
</replacementValue>
</dynamicValues>
<files>
<file>*.*</file>
<file>**\*</file>
</files>
</package>
<email from="bla" mailhost="bla" port="25" userName="bla"
password="bla" includeDetails="TRUE" useSSL="FALSE">
<users>
<user name="User1" group="Portal" address=""/>
</users>
<groups>
<group name="Portal">
<notifications>
<notificationType>change</notificationType>
</notifications>
</group>
</groups>
</email>
</publishers>
</project>
The first error message is probably caused by CCNET service not running because of which the web dashboard can't connect to it. It should go away as soon as you fix the ccnet.config so that service starts running.
The second problem ("Ilegal characters in path"; you seem to have already figured out the missing nodes part) is caused by msbuild/executable element. It seems that CC.NET doesn't like whitespace and especially new line characters inside it's value. Replacing:
<executable>
C:\WINDOWS\microsoft.net\Framework64\v3.5\MSBuild.exe
</executable>
with:
<executable>C:\WINDOWS\microsoft.net\Framework64\v3.5\MSBuild.exe</executable>
should fix the problem.
Another hint: when you're having problems with the validity of your ccnet.config file, try using CCValidator.exe (it's in your CruiseControl.NET\server folder). It usually points out the problematic part of the config file quite nicely (although that wasn't the case with "Illegal characters in path" problem - I had to comment out specific parts of the config to find the offending node).
The first message you receive (connection actively refused) makes me think of a firewall which is blocking the port you're using.
The second problem could be anything. It could for instance be an error in your XML configuration (ccnet.config) file. Can you find any pointers in the Windows Eventlog ?
Regarding the 2nd problem: did you try to run the CC.NET server from the command line?
If you've got an error in your XML configuration, this will give you a more meaningful error message.
Which account are you using to run the Windows service?
Have you checked your ccnet's dashboard.config file?
It has the following line in it:
<server name="local" url="tcp://localhost:21234/CruiseManager.rem" ... />
Try changing the port on that to 82 and then restarting the website (you should be just able to add a space to the web.config file and save and IIS will restart the website).
Sounds like you're confusing two different functions:
tcp://localhost:21234
This is the default remoting port for clients like CCTray. This is not used for the IIS web site (dashboard).
Configuration document is likely missing Xml nodes required for properly populating CruiseControl co nfiguration. Missing Xml node (packageList) for required member (ThoughtWorks.CruiseControl.Core.Publishers.Package Publisher.PackageList)
Your example config is missing required packageList node.
A misleading error message. The port really is 21234, not 82. I got the same errors. The fix was to start ccnet.exe from the desktop shortcut to discover that the real problem was illegal code in my ccnet.config file.
After fixing the ccnet.config file, the problem moved on. When attempting to build, the system would not let the subversion client modify the read-only marker files in the checked out repo.
In my case I misprinted project configuration file name in ccnet.config instead of timescheduler.config it were timesheduler. When I fixed file name I was able to run ccnet service.
<cruisecontrol xmlns:cb="urn:ccnet.config.builder">
<cb:include href="definitions.xml" xmlns:cb="urn:ccnet.config.builder"/>
<cb:include href="projects/timescheduler.config" xmlns:cb="urn:ccnet.config.builder"/>
</cruisecontrol>