Calling the JBoss command line tool Twiddle, located in $JBOSS_HOME\bin directory, can give us the port number on which JBoss is listening for HTTP requests (see Q2366489). That's smashing :)
However, we can't rely on the fact that the system administrator has set the JBOSS_HOME path variable, and it would be useful to know if we can obtain this directory programatically from within the JBoss environment. In my case the project is deployed as a WAR file.
TIA
This, and various other path-related values, are set by JBoss as system properties, which you should use to obtain them.
For example, the system property jboss.home.dir will be set to the equivalent of $JBOSS_HOME, regardless of how the server is actually started.
The various system properties are defined in org.jboss.system.server.ServerConfig.
So:
String jbossHomeDir = System.getProperty("jboss.home.dir");
Related
Any good suggestion for Monitoring JBOSS 7 in Production ? I would also like to configure alerts based on certain condition. Of course , It has to be Open source.
Thanks.
You can use standard JConsole that comes with JBoss dependencies added. It's used to monitor your servers state and mbeans, it's very useful.
To test it on localhost start your server and then run the JConsole from your server/bin directory and select JBoss in the Local process selection.
To use it on "remote" server, start your server on "REMOTE_HOST" and then run JConsole from an JBoss/bin directory and connect with the followin string
service:jmx:jmx-remoting://REMOTE_HOST_NAME:9999 (or the port you use) and enter the username and password.
Secondly, for more detailed info of objects creation, memory leaks, CPU% (profiling) there is another one as:
http://jbossprofiler.jboss.org/
You can try to use free open source APM like scouter.
It shows very useful realtime performance information of every request.
And also you can set a threshold of resources and can make plugin for alerting to external.
https://github.com/scouter-project/scouter
JBoss7 need to set module option.
-Djboss.modules.system.pkgs=~~~,scouter
In my installer i need a number of launchers, to install them as services, based on the user input. Those Launchers are all the same except for an index in their name.
I dont want to create all those launchers manually because that would be impossible to maintain.
Is there a way to copy and modify launchers at installer runtime and then install them as a service?
There is no reason to duplicate a service launcher at runtime. You can use an "Install service" action to install several services with different service names. To do that select "Other service executable" in the "Service" property of that action, then you can select and executable and a (variable) service name as well as variable arguments.
I have a Usecase too, where i want to have this Possibility of Renaming the Launcher an Runtime.
Assume you want to have a Testinfrastructure, where you want not only to test one Instance of your Programm, but several. And you want to use the Launchers from Install4J to start your Application.
Assume you have 5 Services that need to be started to provide the desired Functionality. Now think of having 10 Instances for 10 Customers, you want to test. Further you want to test it not on 10 different Machines, Docker, VM's, or what ever but on one single Machine.
This isn't possible, since you can't rename the Services at Runtime.
Wolfgang, i understand your Problem. Mine is similar.
I played a bit around with the Launcher.exe.
Perhaps there's a Solution for your Case.
Assuming your desired Launchernames are all off the same Length, like:
- Launcher_01.exe
- Launcher_02.exe
- Launcher_03.exe
- Launcher_04.exe
- Launcher_05.exe
You can then generate a Launcher once, with the Name "Launcher_xy.exe".
It's now possible to open up your favorite Hex-Editor an search for "Launcher_xy", rename it to "Launcher_01" and save the Data back to the exe-File. But be aware of not changing the Length of the Name. It won't work, if you'll change the Length.
So if you've changed the Name and afterwards execute
Launcher_xy.exe -install non-interactive
you will get a new Service called "Launcher_01.exe" under Windows-Services.
does any one know how to deactivate the automatic clustering in a JBoss 5.1.0?
we have a JBoss running on each developer machine and because we are all in the same network, they do an auto clustering. The problem could be solved if each of us could get its own multicast ip, but the network hardware is not capable of that.
Isn't there a switch in jboss to deactivate this?
Under Eclipse under Windows, you can run the server using the following JVM property (see Open Launch Configuration) :
-Djboss.partition.name=${env_var:COMPUTERNAME}
This way each of the developer machine will have its own cluster (with a single server if you run only one server). Under Linux, you will need to replace COMPUTERNAME by HOSTNAME.
If you run JBoss AS from the command line, you would use something like -Djboss.partition.name=%COMPUTERNAME% under Windows (not tested).
Note that using -Djgroups.udp.ip_ttl=0 (as proposed in another answer) has the following drawbacks:
server startup is slower (4 minutes instead of 1 minute in my case);
there are a lot of NAKACK warn/error logs;
the JGroups UDP multicast is limited to the local machine which could conflict with other applications based on JGroupds UDP;
other servers on the same machine with the same configuration will be in the same cluster, which may not be desired.
You can use different multicast or partition name to avoid conflict.
However, if you want to disable clustering in "production" or "all" configuration , you need to do following actions:
Remove
farm/
deploy-hasingleton/
deploy/cluster/
In deploy/messaging/*-persistence-service.xml, change Clustered to false:
<attribute name="Clustered>false</attribute>
and remove
<depends optional-attribute-name="ChannelFactoryName">jboss.jgroups:service=ChannelFactory</depends>
In conf/bootstrap/profile.xml, replace
<bean name="BootstrapProfileFactory" class="org.jboss.system.server.profileservice.StaticClusteredProfileFactory">
with
<bean name="BootstrapProfileFactory" class="org.jboss.system.server.profileservice.repository.StaticProfileFactory">
and remove the "farmURIs" property a few lines below that.
Replace deploy/httpha-invoker.sar with http-invoker.sar from the default profile
In the deployers/clustering-deployer-jboss-beans.xml, comment out WebAppClusteringDependencyDeployer.
In SOA-P, if you are removing clustering, you will need to take a few additional steps.
Copy the server/default/deploy/jbpm.esb/hibernate.cfg.xml to server//deploy/jbpm.esb/hibernate.cfg.xml
Remove server//deploy/riftsaw* and cp -R server/default/deploy/riftsaw* server//deploy/
You can do this by setting the TTL (time-to-live) on the multicast packets to zero. Clustering will still be enabled, but none of the JBoss servers running on the developer machines will be able to locate each other.
When starting JBoss, set the jgroups.udp.ip_ttl system property, e.g.
-Djgroups.udp.ip_ttl=0
You'll need to hack that into the JBoss startup script, most likely.
I found couple of tutorials how to run multiple instances of JBoss on the same machine.
All of them mention uncommenting Service Binder and having separate service-binding.xml files for each server.
The question is why it's done like that? Is there any reason except adding additional layer of indirection?
It looks the same could be done by modification of ports in jboss-service.xml for each server. The only restriction would be that there won't be easy way to switch which instance of JBoss uses which set of ports.
You are right with modifying the ports in jboss-service.xml. This is the straightforward and genuine way to change the ports.
Unfortunately, ports are not only defined in that file, but also in other places like jboss-web's configuration etc.
Catching all those places can be error prone.
So the idea was to have a central file (service-binding.xml) that lives in the root of a server installation. You basically copy the 'default' config to server1, server2 etc and then via command line pass in the server name when starting so that the correct port-offset for all of the services is taken from service-bindings.xml and applied to the resulting runtime configuration.
JBossAS 7 takes this concept one step further to the ServiceBindingGroups, where the base ports are defined on a domain level and then per server you pick a basic group + just a port offset by name, so that there is even less work needed than in as4
We have multiple instances of JBoss 5.1.0 running on the same physical server, using multiple instances of the same VM:
<JBOSS_HOME>/server/instance1
<JBOSS_HOME>/server/instance2
with the appropriate configuration to avoid port clashes etc.
For each instance there is the tmp folder:
<JBOSS_HOME>/server/instance1/tmp
<JBOSS_HOME>/server/instance2/tmp
To keep things separate, is it ok to set the java.io.tmpdir variable to <JBOSS_HOME>/server/<INSTANCE>/tmp?
Thanks in advance
Rich
Probably, but JBoss might be assuming it has full control over the contents of that directory. It might be a good idea to create a directory under <INSTANCE>/tmp, and set java.io.tmpdir to that, it would likely reduce the risk of any collisions.