If you are modifying your java application to use Oracle Real Application Clustered (RAC) Database instead of standard single-node database server (Express or Standard edition), then you need to modify settings of your JDBC driver.
It’s very easy to configure custom SSLSocketFactory for JAX-WS web-service: just specify custom property referring to SSLSocketFactory bean.
But there is a nuance…
When developing java web application it is often annoying to manage third-party javascript libraries. Especially, when it is necessary to upgrade some of them.
The project “WebJars” makes a life easier for such lazyefficient developers, like me :-)
There is a wide range of popular javascript libraries packaged int Jar archives and ready to be included as a dependencies into your project. It is described in the documentation how to configure resource mapping in a web framework of your choice.
Very often there is a need to monitor the Java application server. For example, external monitoring tool, like Nagious/Zenoss/Zabbix needs to get some metrics, like heap memory usage or thread count.
Usual way to get that metrics is to setup access to application server via JMX.
But, sometimes, it is not possible to leave some other port opened for JMX and the only port available is HTTP(80 or 8080) or HTTPS(443 or 8443).
Here the Jolokia comes to rescue!
JSON has became a de-facto standard for webservices, replacing XML web services. It has native support in web browser clients.
That makes JSON is the standard of choice for UI-oriented services. It has a good support on mobile devices. Also, it provides smaller data payload size compared to XML and it’s very sufficient for high-load systems as it saves a traffic. But what is for data validation? For XML web services there is a XML Schema. It comes ti mind, that similar standard for JSON should be called “JSON Schema”. And it really exists!
Setting entropy pool for Java server on linux is fair simple. Just add a system property to specify a device to read from.
Chronicle by Peter Lawrey:
This library is an ultra low latency, high throughput, persisted, messaging and event driven in memory database. The typical latency is as low as 80 nano-seconds and supports throughput of 5-20 million messages/record updates per second.
This library also supports distributed, durable, observable collections (Map, List, Set) The performance depends on the data structures used, but simple data structures can achieve throughput of 5 million elements or key/value pairs in batches (eg addAll or putAll) and 500K elements or key/values per second when added/updated/removed individually.
It uses almost no heap, trivial GC impact, can be much larger than your physical memory size (only limited by the size of your disk) and can be shared between processes with better than 1/10th latency of using Sockets over loopback. It can change the way you design your system because it allows you to have independent processes which can be running or not at the same time (as no messages are lost) This is useful for restarting services and testing your services from canned data. e.g. like sub-microsecond durable messaging. You can attach any number of readers, including tools to see the exact state of the data externally. e.g. I use; od -t cx1 {file} to see the current state.
There is no sense to run profiler in instrumentation mode on a high load.
Instead of using instrumentation you should use sampling mode.
This article describes the difference between instrumentation and sampling modes. JVisualVM is a good free tool for this task.
When configuring executors in multithreaded application, do not forget to assign names to your threads. It simplifies later profiling a lot, when you see a meaningful thread names in your profiler.
For example, you may use CustomizableThreadFactory from SpringFramework for that.