I'm using Apache Karaf 2.3.3 with Jetty 9.0.7 bundles installed. Jetty is hosting a Spring-MVC based application which is a RESTFul web service.
When running a benchmark using Karaf + Jetty, on a specific hardware setup I'm getting speed of 40k HTTP operations per second. If I use standalone Jetty (the same version) - it is over 60k HTTP operations per second.
I have default configuration of both Jetty servers, and I can't see any differences. In both cases I set -Xmx to 6G, but tried with various settings. JRE is 1.7.0_45.
CPU and memory consumption reported by the operating system (Ubuntu) is similar in both cases.
Karaf is configured to use Equinox under the covers.
Any ideas?
Related
Will PCF run the Tomcat embedded in Spring boot jar or it runs its own tomcat. In PCF we never mention the port number. In the classic approach, we start 3 Tomcat instances in different port number and have apache server before that. Does PCF work the same way.
This is a pretty broad question, so I'm going to answer with a pretty broad response but link you to where you can find more details, if you are inclined to dig in more.
How PCF works internally when deploying Spring boot project
Will PCF run the Tomcat embedded in Spring boot jar or it runs its own tomcat.
When you run cf push -p my/cool/file.jar (or even file.war), the cf cli extracts everything from that archive and pushes it up to CF. CF stores your app files & then your app is staged.
During staging, the Java build pack runs. It looks at all the files that were pushed & tries to determine what to do with them. It knows how to handle several different types of apps [1], including both standard WAR files & Spring Boot apps. The build pack will check your app to see if its one of the supported types in order [2] and will select the first match.
After selecting the type of app, it runs through and installs what is necessary to run your app. For a Spring Boot app, that's basically just the JVM. For a WAR file, it installs Tomcat & a JVM. In addition, it writes out the configuration & start up commands necessary for CF to launch your app.
At this point staging is complete and you have what is called a "droplet". If you have any additional questions on the staging workflow, read here for more details [3].
At this point, the app would be started. The platform takes the droplet that was created and executes the command specified by the build pack to start the app [4]. If all goes well, your app will then be up and running on CF.
In PCF we never mention the port number.
Correct. The platform will tell you the port on which your application should listen. For Java apps, you don't have to do anything. The Java buildpack will handle configuring Spring Boot or Tomcat to start and listen on the correct port.
For Spring Boot apps, you can look at the start up command to see how it's doing this. For Tomcat, it happens in the server.xml that's generated by the Java buildpack [5].
In the classic approach, we start 3 Tomcat instances in different port number and have apache server before that. Does PCF work the same way.
Yes and no. Each application you run can have multiple instances. If you scaled your app to have three instances, that would be roughly like having 3 Tomcat instances in your classic approach.
The main difference is that there would be no Apache Web Server in front. On Cloud Foundry, this is not necessary because it has it's own load balancer called Gorouter [6] which handles proxying traffic to your app and load balancing across available app instances.
This is a classic mistake that people new to CF make. They try to replicate classic architectures and shoehorn a reverse proxy into their app when it's not necessary. This is one of the benefits of CF. It handles routing traffic to your app in a scalable way, freeing you up to focus more on your app.
[1] See "Standard Containers -> https://github.com/cloudfoundry/java-buildpack#additional-documentation
[2] https://github.com/cloudfoundry/java-buildpack/blob/master/config/components.yml#L18
[3] https://docs.cloudfoundry.org/concepts/how-applications-are-staged.html
[4] https://docs.cloudfoundry.org/concepts/overview.html#apps-anywhere
[5] https://github.com/cloudfoundry/java-buildpack/blob/master/resources/tomcat/conf/server.xml#L21
[6] https://docs.cloudfoundry.org/concepts/architecture/#routing
No. The simple answer is each instance of ur application jar is running in its own container within PCF. So there is no clash of using the same port numbers.
I have got WebSphere Application Server base version and I need to deploy application in horizontal cluster. Can that be achieved without Network Deployment version?
You cannot create and manage cluster on base version.
What you can do, is so called Simple load balancing. So you have 2 separate servers, where you have to manually, separately deploy same application and configure IBM Http sever to do the load balancing among these 2 servers.
So you have a failover and load balancing, but without centralized management.
I'm evaluating options for my team's middleware. We really have a frankenstein'd setup. We're using Apache ServiceMix(Karaf/ActiveMQ/CXF), Websphere 8.5, ActiveMQ where we don't really need it, and all of our applications are not really coded to failover to another node if the primary goes down. We realized the issues of our setup and now want to improve.
We currently host bundles (not sure if they're all OSGI compliant) in a Karaf Container, which are used via ActiveMQ after being sent JMS messages via Apache Camel from Websphere.
My current idea is to kill off ActiveMQ, make all the camel routes towards HTTP (instead of JMS queues), and convert our data bundles/services to serve via HTTP through Apache CXF (replacing websphere for some things) and not ActiveMQ Queues/JMS. However, we have Websphere licenses, and I do know that it supports bundles in some way, I'm just not as familiar as to how it does (same nature as karaf)?
The main question is in the title, and I hope it's not too generic.
WebSphere 8.5 is a full OSGi container supporting Blueprint just as Karaf does.
You can, in theory, run your camel bundles or whatnot just as fine in WAS8.5. However, Apache Karaf is a lot more aligned towards running ActiveMQ/CXF/Camel stuff than WebSphere will ever be. Installation in Karaf is a few commands, where installation and configuration struggle in WAS85 for the Camel feauters and basic camel routes is .. well, a headace when I tried it last time. Others seems to have the same struggle.
I have rather good experience of running Camel apps inside WebSphere Application Server, but that was by embedding Camel in a standard WebApp, not using the OSGi stuff. So, embedded web apps is my recommendation for running Camel inside WebSphere.
For the "replace AMQ/JMS with HTTP" part. You are aware of that you are replacing pears with apples, right? JMS has a lot of features HTTP does not have (and some overhead compared to HTTP). For the sake of completeness, WebSphere also has a JMS provider built in. So if you have a large HA secured WebSphere infrastructure, the WebSphere (SIBus) provider might be a good choice. Otherwise, ActiveMQ rocks :-)
Does anyone know if its possible to re-configure CometD to use the WebSphere Application Server instead of using Jetty? If so, is there much effort involved in porting it over if I've already got CometD running with Jetty?
CometD runs in any Servlet 2.5 or later Servlet Container, see here.
You did not specify the WebSphere version, but I assume it's a recent enough one.
The only CometD feature that will not work in WebSphere is the WebSocket transport, which is Jetty specific due to lack of standard WebSocket API (now filled by JSR 356 and supported soon in CometD 3).
Your CometD application should deploy and run with no changes in WebSphere, unless you tied yourself explicitly to Jetty APIs.
We have a swing UI that is a restlet client. We are accessing the services on the LAN, but the communication is taking a bit long. We are using Tomcat 7.0 and mysql on the server side.
Is it a known issue with restlet based applications ?
How can we speedup the communication time?
In version 2.0 the internal HTTP client isn't designed for speed/production purpose, more for developement/convenience purpose. This has been redesigned in version 2.1.
However, in version 2.0, you can drop "org.restlet.ext.net.jar" in your classpath to switch from the internal connector to a faster one based on HTTPUrlConnection.