From my understanding of domain mode operations is the following:
Host level: configuration will apply to all servers that are defined in host-slave.xml
Server group level: configuration applies to all servers that are part of the group
I'm using Jboss in domain mode, all slave machines startup pointing to the domain master and includes host-slave.xml, from Jboss admin portal, I have created number of groups, and I have assigned slaves to groups accordingly, however every time I restart jboss on any of the slaves, it comes back pointing to default server groups
<server name="server-one" group="main-server-group"/>
<server name="server-two" group="other-server-group">
And I have to go to that server and change the group, I have tried modifying group portion in host-slave.xml to correspond to the group I would like them to be part of, however I'm getting exceptions when starting up the server.
What am I missing here? is there is a way to have group level config override settings defined by host-slave.xml
Add <server name="server-one" group="main-server-group"/>
<server name="server-two" group="other-server-group">them in the host.xml and start them it should reflect. While start up it checks for host.xml.
Related
I have introduced LRA on a MicroProfile application already running on WildFly AS.
To get the LRA working I have added the following depedency on my application pom.xml
<dependency>
<groupId>org.jboss.narayana.rts</groupId>
<artifactId>narayana-lra</artifactId>
<version>5.10.6.Final</version>
</dependency>
and I have created an LRA coordinator running on the same host ad listening on port 8080.
The application works as expected.
Now I want to move LRA coordinator on a remote host, but I'm not able to configure my application to point to it (on new host and port).
I have tried to put in my microprofile-config.properties the following parameters:
mp.lra.http.host=<new_host>
mp.lra.http.port=<new_port>
but without effect.
Can anyone suggest me hot to configure LRA coordinator host and port on client application?
Thanks in advance
Narayana doesn't support MicroProfile Config yet even if it is something that it probably should. The properties you want to set are defined only as system properties (i.e., read with System.getProperty(String, String).
Another issue is that the properties you are looking for are defined as lra.http.host and lra.http.port respectively. MP LRA made a deliberate decision to remove all coordinator references from the specification to not specify the implementation architectures (saga can also be implemented as an orchestration pattern).
So you need to set these system properties for instance when you are starting the WildFly server:
bin/standalone.sh -Dlra.http.host=lra-coordinator.com -Dlra.http.port=7777
Finally, if you ever move to the latest Narayana releases, these properties were merged only into single property lra.coordinator.url which is however still read only from system properties.
We have setup weblogic 12.2.1.4 clustered environment with 2 nodes in a cluster. We use session ID as part of authentication mechanism to log our user session info to the database. When both managed servers are up, the server generates this session ID:
MrvgJEMe6NG95XNsflnhsWjspl52GXPdl33whbIfGkgaEQm7Rk0X!1974917613!-533469515!1605782630842
When we tried to test session replication, by bringing down the server that currently serves the HTTP request, we have noticed that the session ID has changed and contains NONE as part of the generated ID.
MrvgJEMe6NG95XNsflnhsWjspl52GXPdl33whbIfGkgaEQm7Rk0X!1974917613!NONE!1605782630842
This has caused session replication inconsistency. Has anyone encountered the same issue and how did you resolve it? Your inputs are highly appreciated.
Thank you in advance for the help.
Enable the Debug Flags to Track Session Replication Failures
To gather more logging information about session replication failures, you should enable the flags DebugCluster, DebugClusterAnnouncements, DebugFailOver, DebugReplication, and DebugReplicationDetails.
To Enable:
In WebLogic Server 9.x and higher, the reccommended approach is to use the admin console. For each server in the domain, navigate to Servers -> -> Debug and enable the desired flag(s).
You can use the weblogic.Admin command line utility to dynamically turn the debug options on and off.
For example, to turn on DebugCluster on all administration instances of ServerDebug Mbean (i.e., Admin Server or a Managed Server):
java weblogic.Admin -url t3://localhost:7001 -username system -password weblogic SET -type ServerDebug -property DebugCluster true
Alternatively, you can edit the config.xml and the Mbean element in the stanza for each server that you want to debug and set the value to "true" to enable or "false" to disable. Then you must restart the Admin Server. Managed Servers will reconnect to the Admin Server and the debug flags will then dynamically take effect. Example:
At the end, with all the flags set, in your config.xml the ServerDebug tag would like below:
Make sure the stdOutSeverity level of the server is INFO and StdoutDebugEnabled is set to "true". The debug information will be logged into the server log as well as to the standard out.
Validate the Weblogic.xml entries
Make sure weblogic.xml has all the parameters that need to be set for each Session Replication type. For example, when using in-memory replication the sample weblogic.xml would look like:
Supposing I have info.name=bruce stored in config server A but server A hasn't started yet. Now I start a client with local configuration info.name=Neo. Apparently info.name is equal to Neo for this client. I think info.name should be replaced with bruce if I start config server A, but in fact info.name is still Neo.
So my question is if client starts without config server, will it retrieve configuration again when config server starts?
I've figured it out. Local configuration takes priority of the remote's because of the absence of the config server(Client will load local configuration first). Removing the info.name property from client configuration solved my problem.
In JBoss 7.1.1 in standalone mode all JNDI bindings are configured in standalone.xml file in jboss:domain:naming:1.1 subsystem. According to documentation standalone.xml cannot be modified when server is running. I've tried to use JBoss CLI but I don't know how to write/modify resource.
How to change value in JNDI without restarting jboss?
Should help you: https://docs.jboss.org/author/display/AS71/JNDI+Reference
Topic - Binding entries to JNDI:
An example standalone.xml might look like:
<subsystem xmlns="urn:jboss:domain:naming:1.1" >
<bindings>
<simple name="java:global/a" value="100" type="int" />
<object-factory name="java:global/b" module="com.acme" class="org.acme.MyObjectFactory" />
<lookup name="java:global/c" lookup="java:global/b" />
</bindings>
</subsystem>
To add these entries via the CLI:
/subsystem=naming/binding=java\:global\/mybinding:add(binding-type=simple, type=long, value=1000)
To see all all options that are taken by the add command (this can
actually be used to get the description of any CLI command):
/subsystem=naming/binding=*:read-operation-description(name=add)
Have not tried, but i hope this helps!
UPDATE - with tested examples:
Add JDNI name binding java:global/a:
/subsystem=naming/binding=java\:global\/a:add(value=10,binding-type=simple,type=java.lang.Integer)
Read existing JDNI name binding java:global/a:
/subsystem=naming/binding=java\:global\/a:read-resource(include-defaults=true)
Modify JDNI name binding value java:global/a:
/subsystem=naming/binding=java\:global\/a:write-attribute(name=value, value=20)
Remove JDNI name binding java:global/a:
/subsystem=naming/binding=java\:global\/a:remove()
Executing command directly from shell:
./jboss-cli.sh --connect --command="/subsystem=naming/binding=java\:global\/a:read-resource(include-defaults=true)"
The question has a lot of views so I'll answer to it. Inspired by #mik response I've figured out that to change value of some JNDI key e.g. java:jboss/api/key to newApiKey run JBoss CLI and execute:
connect
/subsystem=naming/binding=java\:jboss\/api\/key/:write-attribute(name=value,value=newApiKey)
The change will be immediately visible on server and also stored (updated) in standalone.xmlso it won't get lost after server restart.
I was looking exactly for how to add or modify a JNDI binding at runtime, but I needed to to do this in a Wildfly 9 domain (cluster) configuration (not standalone), which is pretty much the same configuration as JBoss 7. However, I couldn't figure out a way to effectively apply changes without restarting all servers.
To start with, enter the JBoss command line interface and connect to your server domain controller:
./jboss-cli.sh
connect
First, you need to find which profile is active on the server group, so as, on the server root /, enter the following commands:
cd server-group=
ls
Afterwards, you should enter the only server group shown in the listing command (ls) by typing cd {{your_server_group_name}}, then type ls again and look for an entry named profile to check which one is active. Let's consider full-ha as an active profile for our example.
Next, go back to the root configuration folder / by typing cd .. and enter the following commands to navigate and view all JNDI bindings available with their current values:
cd profile=full-ha/subsystem=naming/binding=
:read-resource(recursive=true)
By doing this, you'll be able to see all available JNDI bindings and their attributes, if you want to list only binding names, type ls instead of the last command.
In order to modify a binding, type cd and the name of the binding listed in the previous command. Let's suppose you want to change the value of a binding named java:/webservice.url, then you should enter
cd java\:\/webservice.url
Notice that is necessary to quote some characters in your binding name such as : (colon) and / (slash) with a backslash (\).
To modify an attribute within this binding you should use the :write-attribute command. In this example, let's suppose you want to modify (or add) an attribute named "value" with its content as "this is a value":
:write-attribute(name=value,value="this is a value")
So as to apply this change, you'll need to restart all servers in the cluster by typing the following command:
/server-group={{server-group-name}}:restart-servers
If you want to know more commands to add or remove JNDI bindings check this jboss-cli snippets page
This configuration has been tested successfully in Wildfly 9.0.1
I need to run multiple(more than 4) instances of JBoss server on a single machine.
I am using JBoss 4.2.3 GA.
I found the answer. We have to configure the jboss-service.xml to run multiple instances in the same machine.
We may need to keep the same "default" instance same as it is under the JBOSS_HOME\Server.
We have to create another folder say "instance2" under JBOSS_HOME\Server.
Copy all the contents from JBOSS_HOME\Server\default to this newly created folder.
Now goto conf folder under JBOSS_HOME\Server\instance2 directory.
Edit the jboss-service.xml.
Search for mbean code="org.jboss.services.binding.ServiceBindingManager" in this configuration file.
By default this xml tag is commented. We have to un comment it and change the value ports-00 to ports-01.
Then start this instance2 jboss instance. We can access this application by using the port number 8180.
We can go for at maximum of 3 instances with this way.
To run more than this we have to add some more running tags in
JBOSS_HOME\docs\examples\binding-manager\sample-bindings.xml.
You can make things a lot simpler by simply changing the IP that the server is bound to.
You will need to copy the entire jboss folder several times and configure run.bat to use the -b parameter on startup.
If this is a Windows server and you're running jboss as a service, you might want to edit the service.bat for each instance too so that the servers all have different names in the services control panel.
Part of the problem we ran into when trying to use different HTTP ports was that jboss uses 'lots' of ports for different purposes and it was a pain to edit all of these port numbers to be unique on each instance. By changing the bind address you can avoid this problem entirely.
Create multiple loopback adapters and bind each ip address to different instance.
No need of changing port.
RK
1) Copy the default folder with new name: instance name
2) In jboss-service.xml Uncomment the ServiceBindingManager mbean and change the ServerName to ports-01 or 02 or 03 e.g:ports-01 and ports-01/02/03 configuration should be there in sample-bindings.xml(present in docs/examples/binding-manager) And make the changes in all the ports mentioned under ports-01/02/03 tags, So that ports will not get conflict. Remember the server will run on the binding port like 8080/8180/8182.
from cmd promt go to the bin folder and run the instances with cmd:
run -c instancename
Running multiple instances of JBoss on the same server:
We should keep the "default" instance same as it is under the **JBOSS_HOME\Server
Copy the default folder with new name (instance name) say default2 under JBOSS_HOME\Server. Copy all the contents from JBOSS_HOME\Server\default to this newly created folder.
The binding service manager needs to be enabled in conf/jboss-service.xml for instances that are not using the default ports.
a. (i.e.) In the copied instance, go to conf folder under JBOSS_HOME\Server\default2 directory. Edit the jboss-service.xml.
b. Search for mbean code="org.jboss.services.binding.ServiceBindingManager" in this configuration file.
c. By default this xml tag is commented. We have to uncomment it and change the value ports-00 to ports-01.
In the same file, Under "Socket transport Connector", in the "Configuration" section, serverBindPort must be changed to another value or it will conflict with the default (4446).
<mbean code="org.jboss.remoting.transport.Connector"
name="jboss.remoting:service=Connector,transport=socket"
display-name="Socket transport Connector">
...
<attribute name="Configuration">
...
<attribute name="serverBindPort">25447</attribute>
...
In default2/deploy/ejb3.deployer/META-INF/jboss-service.xml, for the remoting.transport.Connector mbean, port 3873 must be changed to another value or it will conflict with the default.
<mbean code="org.jboss.remoting.transport.Connector"
name="jboss.remoting:type=Connector,name=DefaultEjb3Connector,handler=ejb3">
<depends>jboss.aop:service=AspectDeployer</depends>
<attribute name="InvokerLocator">socket://${jboss.bind.address}:25874</attribute>
...
In default2\deploy\jboss-web.deployer\server.xml
set redirect port value to the one configured in step 4
<Connector port="8180" address="${jboss.bind.address}"
maxThreads="250" maxHttpHeaderSize="8192"
emptySessionPath="true" protocol="HTTP/1.1"
enableLookups="false" redirectPort="25447" acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true" />
Also, the port value configured in step 5
<!-- Define an AJP 1.3 Connector on port 8009 -->
<Connector port="25010" address="${jboss.bind.address}" protocol="AJP/1.3" //change the connector port value to avoid conflict
emptySessionPath="true" enableLookups="false" redirectPort="25874" /> // port value configured in step 5
In summary, the directory structure for setting up two other instances would be something
like the below with modifications in the filenames in bold.
$JBOSS_HOME/server/default
$JBOSS_HOME/server/default2
$JBOSS_HOME/server/default2/conf/jboss-service.xml
$JBOSS_HOME/server/default2/deploy/ejb3.deployer/META-INF/jboss-service.xml
$JBOSS_HOME/server/default2/deploy/jboss-web.deployer/server.xml**
$JBOSS_HOME/server/default3
$JBOSS_HOME/server/default3/conf/jboss-service.xml
$JBOSS_HOME/server/default3/deploy/ejb3.deployer/META-INF/jboss-service.xml
$JBOSS_HOME/server/default3/deploy/jboss-web.deployer/server.xml**
7.From command prompt go to the bin folder and run the instances with cmd:
run -c instancename
In this case, it is: run -c default2
And applications accessed with url’s like:
http://localhost:8080/myapp/
http://localhost:8180/myapp/
http://localhost:8280/myapp/
Note: We can go for maximum of 3 instances with this way.
To run more than this we have to add some more running tags in JBOSS_HOME\docs\examples\binding-manager\sample-bindings.xml.
I used this article to install mine.
http://wiki.adempiere.net/Setup_2_Adempiere_JBoss_server_in_1_physical_server
You should create different services to control the adempiere servers.
Also if you work with jasper report, use unique file names for reports or you will face permission denied exception.
Ex : if you attach "report.jrxml" to two servers. Server will create /tmp/report.jrxml tmp file.
The second server will also try to create the same file and get crashed
Copy complete JBOSS setup to new location, and start new server with offset option, which will start server on existing ip and changing port to previously_configured_port+offset
standalone.bat -c standalone-full.xml -Djboss.socket.binding.port-offset=100
This command will make default jboss console 9990 to 10090
Now you can add your war file in new deployments folder and start deployment on new port
The quickest and easiest way that comes into mind is simply configuring multiple IP addresses to the hosting machine. Then you can use the different IP addresses to bind to each instance. Doing this means you don't have to change any default ports and allows for an easier environment to manage.
We can easily do this on JBOSS EAP
For first instance, just start the JBOSS as it is.
for the second instance,
Copy the JBOSS home folder to a different location.
go to standalone/configuration/standalone.xml. go to the section(at bottom of the file) and set port-offset value to some value(EX: 10000) which doesn't have any port binding issue on currently running application. Here the default port-offeset value is 0.
start the second instance as usual .