ModeShape is a distributed, hierarchical, transactional and consistent datastore with support for queries and full text search. It also supports versioning, events, locking and even more. Clients can use the JSR-283 Java API to access the Modeshape repository (also known as JCR), the Modeshape REST API, or the JDBC driver that can be used to query the content using SQL syntax.
The purpose of this post is to explain how to work with Spark: a micro-framework that let us quickly create a REST services layer. Spark is the Java porting of Sinatra: famous micro-framework written in Ruby. With Spark it’s possible to start a REST web server with a few lines of code, as we can see in this very simple example.
Do you want to learn how to change the default ports in WildFly application server? Then keep reading this tutorial!
Port offset is an useful tweak which can be applied to execute several application servers on the same machine. A typical usage of the port-offset is for creating a vertical cluster, with multiple nodes on the same machine.
In standalone mode, the port offset is contained in the standard-sockets definition:
<socket-binding-group name="standard-sockets" default-interface="public"
port-offset="${jboss.socket.binding.port-offset:0}">
<socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
<socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
<socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
<socket-binding name="http" port="${jboss.http.port:8080}"/>
<socket-binding name="https" port="${jboss.https.port:8443}"/>
<socket-binding name="txn-recovery-environment" port="4712"/>
<socket-binding name="txn-status-manager" port="4713"/>
<outbound-socket-binding name="mail-smtp">
<remote-destination host="localhost" port="25"/>
</outbound-socket-binding>
</socket-binding-group>
As you can see it contains a Beanshell expression which means, unless the jboss.socket.binding.port-offset is set, it evaluates to 0 so to standard sockets.
So by starting the standalone server with:
standalone.sh -Djboss.socket.binding.port-offset=100
...will shift all ports by 100. This means also the management bindings, such as management-http and management-https :
13:36:47,186 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:10090/management 13:36:47,187 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:10090 13:36:47,187 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 14.0.0.Final (WildFly Core 6.0.1.Final) started in 20057ms - Started 1057 of 1226 services (359 services are lazy, passive or on-demand)
If you want to apply the change permanentely in your configuration, then you can achieve the same result with:
/socket-binding-group=standard-sockets:write-attribute(name=port-offset,value=100)
Another thing that not every administrator knows, is that you can assign a fixed port value to a binding. This is usually the case of the HTTP port which is often decided with different rules other than port offset. You can set a fixed port bindings by CLI as follows:
/socket-binding-group=standard-sockets/socket-binding=http:write-attribute(name=fixed-port,value=true)
This results in the following:
<socket-binding name="http" port="${jboss.http.port:8080}" fixed-port="true"/>
Finally, one tricky question could be, how do you bind just one channel (let's say http) to an IP address, while keeping the others on the default interface (loopback) ? That's not too complex to do: you have to define one interface at first with your binding rule:
<interfaces>
. . . .
<interface name="allIPs">
<inet-address value="${jboss.bind.address:0.0.0.0}"/>
</interface>
</interfaces>
Now you can use the interface attribute on the single socket binding:
/socket-binding-group=standard-sockets/socket-binding=http:write-attribute(name=interface,value=allIPs)
This way, you can mix and match the inet address used by the single channels.
When running in Domain mode, you cannot use the property -Djboss.socket.binding.port-offset at start up to shift the port of your Domain Servers.
You must apply the port offset change through the Host Controller that govern the server:
/host=master/server-config=server-one:write-attribute(name=socket-binding-port-offset,value=100)
This results in the following change in the host.xml configuration file:
<server name="server-one" group="main-server-group" auto-start="true"> <socket-bindings port-offset="100"/> </server>
This tutorial is a follow-up to the JBoss AS 7 Performance tuning tutorial. We will focus now on the incoming request flows as they cross the WildFly borders. And we will learn how to monitor the most critical attributes.
If you want to tune a complex beast like a Java application server it is crucial that you understand the single steps that the request performs before reaching the target component. All the rest has usually a minor impact on performance.
So let's see a typical request coming from a Web front-end and reaching WildFly EJBs which in turn invoke the database:
As you can see from the above picture, the thread that is driving a Web based request is Undertow XNIO thread which is created by Undertow handlers. Setting the correct amount of IO threads is crucial in this scenario, otherwise you will have a bottleneck at the beginning of your request.
Provided that there are enough io-threads to serve your http request, the core-max-threads (first) and the task-max-threads (after) are used to determine in the request is served or if it is going to be discarded.
Undertow threads are configured through the IO subsystem. Here is how to set the number XNIO pool for a medium-large sized Web site:
/subsystem=io/worker=default/:write-attribute(name=task-core-threads,value=25) /subsystem=io/worker=default/:write-attribute(name=task-max-threads,value=100) /subsystem=io/worker=default/:write-attribute(name=io-threads,value=100)
Still in the Web layer, you need to take into account the number of sessions which are running. The parameter max-active-sessions is used to determine how many active HTTP session will be allowed. If session creation would cause the number of active sessions to exceed <max-active-sessions/>, then the oldest session known to the session manager will passivate to make room for the new session. That's a big price in terms of performance so let's see how to configure it using jboss-web.xml:
<jboss-web> <max-active-sessions>200</max-active-sessions> </jboss-web>
Then, keep monitoring the number of sessions using the CLI. In order to do that, you need to point to your /deployment path and enter into its undertow subsystem path:
/deployment=webapp.war/subsystem=undertow/:read-resource(include-runtime=true)
{
"outcome" => "success",
"result" => {
"active-sessions" => 1,
"context-root" => "/webapp",
"server" => "default-server",
"sessions-created" => 1,
"virtual-host" => "default-host",
"servlet" => {
"Faces Servlet" => undefined,
"demo.DownloadServlet" => undefined
}
}
}
Once the IO thread reaches the EJB container, an EJB is picked up from the Pool (Stateless EJB) or pinned from the Cache (Stateful EJB). This is the second element that you need to consider in this scenario: that you have enough resources on your EJB Container.
As a matter of fact, if you are using Stateless Session Beans you must be aware that EJB pooling is not enabled by default on WildFly 8. The rationale behind this decision is that an accurate pool size is tightly dependent on your application and cannot be easily guessed. Therefore, a poorly configured pool of EJBs could be even detrimental in terms of performance, causing excessive cycles of garbage collections. For this reasons, it’s up to you to turn on this feature and set a correct configuration for its parameters.
This requires however just as little as a combo box selection from the EJB3 Container tab. Or a simple CLI command:
/subsystem=ejb3/:write-attribute(name=default-slsb-instance-pool,value=slsb-strict-max-pool)
If you are using Stateful EJBs you will rather deal with a Cache of Beans that contain conversational data.
The Stateful cache by default uses a simple caching system which does not involve Passivation of data. This might be desirable in terms of performance, however if you need to use a Passivation mechanism in your application, you must learn how to configure the limits of your cache.
At first you need to enable the SFSB to use a passivation capable cache like the distributable:
/subsystem=ejb3/:write-attribute(name=default-sfsb-cache,value=distributable)
Then, you can configure the maximum number of SFSB allowed in the cache. For example, the distributable cache uses the infinispan passivation-store which allows a maximum number of 10000 elements in the cache
/subsystem=ejb3/passivation-store=infinispan/:write-attribute(name=max-size,value=10000)
Once that you have configured your Pool or Cache, it is time to monitor if your configuration is appropriate. As for the Web layer, you can obtain this information through your deployment unit, by digging into the ejb3 subsystem as follows:
/deployment=myapp.jar/subsystem=ejb3/stateless-session-bean=Manager/:read-resource(recursive=false,include-runtime=true,include-defaults=false)
{
"outcome" => "success",
"result" => {
"component-class-name" => "Manager",
"declared-roles" => [],
"execution-time" => 0L,
"invocations" => 0L,
"methods" => {},
"peak-concurrent-invocations" => 0L,
"pool-available-count" => 20,
"pool-create-count" => 1,
"pool-current-size" => 1,
"pool-max-size" => 20,
"pool-name" => "slsb-strict-max-pool",
"pool-remove-count" => 0,
"run-as-role" => undefined,
"security-domain" => "other",
"timers" => [],
"wait-time" => 0L,
"service" => undefined
}
}
If you have enough resources in the EJB container, then the IO thread will continue its race to the last step which is usually the Database, but could be as well another EIS.
In case you are dealing with Database connections, you must acquire a connection from the pool, that is governed by the JCA layer. The key configuration parameter is max-pool-size which specifies the maximum number of connections for a pool. (Default 20). Note that there will be a maximum limit for the number of connections allowed by the database to match.
You can set your Connection pool max size to a different attribute using this CLI:
/subsystem=datasources/data-source=MySQLDS/:write-attribute(name=max-pool-size,value=50)
Note in this tutorial (Monitor WildFly with your bash skills) we have demonstrated how to monitor the Connection pool with some simple bash and CLI interaction
In the second example, we will cover a slightly different approach which involves remote EJB calls. (Think for example of a remote EJB client).
Since WildFly 8, these calls are not landing directly into the EJB Container, but they are mediated by Undertow which performs an Http upgrade towards the Remoting channel.
What is the main difference with the scenario that we have just covered ? As you can guess from the picture, the IO thread is not any more the driver of the call, but the EJB Thread pool comes into play. You can set the EJB thread pool from the ejb3 subsystem as follows:
/subsystem=ejb3/thread-pool=default/:write-attribute(name=max-threads,value=100)
In this example, we have set it to 100 which should be a fairly high value.
The Undertow threads still have some relevance in this scenario, as they will be used in case you are using async calls to your EJB and for providing the response to the client (Thanks to Stuart Douglas for pointing out this needful information). You can monitor the thread pool at runtime using the following CLI:
/subsystem=ejb3/thread-pool=default/:read-resource(include-runtime=true)
{
"outcome" => "success",
"result" => {
"active-count" => 5,
"completed-task-count" => 13L,
"current-thread-count" => 3,
"keepalive-time" => {
"time" => 100L,
"unit" => "MILLISECONDS"
},
"largest-thread-count" => 5,
"max-threads" => 10,
"name" => "default",
"queue-size" => 0,
"rejected-count" => 0,
"task-count" => 0L,
"thread-factory" => undefined
}
}
In the next WildFly tuning tutorial we will learn one different scenario which involves using JMS into the flow chain.
Other resources you might be interested:
JBoss Performance Tuning part 1
JBoss performance tuning part 2
Speed-up your Enterprise Applications with our WildFly Performance Tuning guide!There are actually many free and opensource tools for monitoring the jboss/wildfly application server. In this article we will learn how to create a monitoring shell using as little as jboss cli and bash and awk.
This tutorial describes how you can configure the ActiveMQ 5 resource adapter on WildFly with a few simple steps.
[Please note, if you want to integrate ActiveMQ Artemis, then check this tutorial: How to connect WildFly to a remote ActiveMQ Artemis server? ]
A few days ago the version 8.2 of WildFly application server has been released. This release includes a number of improvements and bug fixes over the last release, 8.1.0.Final. In this article we will have a look at the web Administration console which bears some interesting changes.
This is the second tutorial about Docker. In the first one Getting started with Docker and WildFly we have learnt how to install Docker on a Linux machine and pull a WildFly image on the top of it. Now we will learn how to deploy applications by using Docker Files.
First of all, what is a Dockerfile? a Dockerfile has a special mission: automation of Docker image creation. Once, you write build instructions into Dockerfile, you can build your own Docker images with custom environment configuration.
A Dockerfile consists of a set of commands which can be written in a text file named "Dockerfile". The purpose of our first Docker file will be adding an application named "helloworld.war" in the deployments folder of the standalone installation. This will trigger automatic deployment.
Here we go:
vi Dockerfile
And enter the following instructions:
FROM quay.io/wildfly/wildfly-centos7 ADD helloworld.war /opt/jboss/wildfly/standalone/deployments/
Now make sure that the helloworld application is in the same folder as the Dockerfile:
[root@localhost docker]# ls Dockerfile helloworld.war
To build a new Docker image is pretty simple, you have to choose a name (actually a tag) and issue a docker build command:
[root@localhost docker]# docker build --tag=wildfly-helloworld . Step 0 : FROM quay.io/wildfly/wildfly-centos7 ---> 365390553f92 Step 1 : ADD helloworld.war /opt/jboss/wildfly/standalone/deployments/ ---> Using cache ---> fc3e0048139e Successfully built fc3e0048139e
So we have successfully built the wildfly-helloworld image. Let's check it by issuing a docker images command:
[root@localhost docker]# docker images | grep wildfly wildfly-helloworld latest 20c2c33016c0 4 minutes ago 1.06 GB quay.io/wildfly/wildfly-centos7 latest 0ed0b7d75892 6 months ago 1.06 GB
So now you can start Docker with just:
[root@localhost docker]# docker run -it wildfly-helloworld
The application server will start. Verify that the console that the application has been started:
18:18:47,682 INFO [org.jboss.as.server] (ServerService Thread Pool -- 28) JBAS0 18559: Deployed "helloworld.war" (runtime-name : "helloworld.war")
Fine, in order to test it, we need to find the IP address which has been chosen by Docker to bind the application server:
[root@localhost docker]# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES b63e7345bf81 wildfly-helloworld:latest "/opt/jboss/wildfly/ 18 minutes ago Up 18 minutes 9990/tcp, 8080/tcp cranky_pasteur
And then:
[root@localhost docker]# docker inspect -f '{{ .NetworkSettings.IPAddress }}' b63e7345bf81
172.17.0.4
Your application is ready to be tested at the address http://172.17.0.4:8080/helloworld
In order to deploy applications using the Web console we will need to add an user with add-user.sh script which is included in the bin folder of the application server. There are several way to do that, but we can have it done while building our image, so let's add to our Dockerfile the following command which will create an user in non interactive mode:
FROM quay.io/wildfly/wildfly-centos7 RUN /opt/jboss/wildfly/bin/add-user.sh admin Admin#70365 --silent
Now let's rebuild our image:
docker build --tag=wildfly-helloworld .
We will start now the application server. Since we need to access the management interfaces from our host machine, we need to bind them as well on the 0.0.0.0 IP (all available IP Addresses).
docker run -it wildfly-helloworld /opt/jboss/wildfly/bin/standalone.sh -b 0.0.0.0 -bmanagement=0.0.0.0
Fine. Inspect for the Container ID using docker ps and find the IP Address used by the application server:
[root@localhost docker]# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 5935f7beb7d0 wildfly-helloworld:latest "/opt/jboss/wildfly/ 50 seconds ago Up 49 seconds 9990/tcp, 8080/tcp stupefied_bell
And then:
docker inspect -f '{{ .NetworkSettings.IPAddress }}' 5935f7beb7d0
172.17.0.5
Now log into the Admin Web console at 172.17.0.4:9990 and enter the credentials we have included into the Dockerfile
Great! we are into the Docker Admin Console.
From there we can access the Runtime tab and add applications which are hosted on our machine.
So far we have learnt about the RUN command to execute the add-user.sh script. We will learn another command which is CMD. The main purpose of a CMD is to provide defaults for an executing container.
CMD ["/opt/jboss/wildfly/bin/standalone.sh", "-b", "0.0.0.0", "-bmanagement", "0.0.0.0"]
The advantage of including this command in the Docker images is that we don't need to specify every time the port bindings.
By the way, what is the difference between RUN and CMD ? With RUN the docker build will execute the commands. With CMD docker run will run this command by default.
So here is the full Dockerfile:
FROM quay.io/wildfly/wildfly-centos7 RUN /opt/jboss/wildfly/bin/add-user.sh admin Admin#70365 --silent CMD ["/opt/jboss/wildfly/bin/standalone.sh", "-b", "0.0.0.0", "-bmanagement", "0.0.0.0"]
Once you have rebuilt your image, you can start your docker image with just:
docker run -it wildfly-helloworld
This is the first of a set of tutorials about the Docker framework. In this one we will learn how to install the Docker platform on a Linux Centos machine and pull and execute a WildFly image on the top of it.
This tutorial has been updated, thanks to the suggestions received on developer.jboss.org. We thank our readers for reporting any issue found in our tutorials.
This is the second article about WildFly clustering API. You can read here the first tutorial: Monitoring a cluster using WildFly API. In this article we will learn how to execute commands on Node/s of the cluster using WildFly's Dispatch API
Today I've found one interesting question on StackOverFlow of one user asking to read the web.xml context params from a CDI Bean. Luckily it's not complicated at all to accomplish this task.
Read more: Accessing ServletContext and ServletRequest in CDI Beans