After reading an interesting article on Erlang  and Java interoperability, I have decided to dedicate my spare time to Erlang.

O’Reilly has just published a wonderful book on Erlang, so I decided to dive into it.

[Read more →]

As processors become faster and multiprocessor systems become cheaper, the need to take advantage of multithreading in order to achieve full hardware resource utilization only increases the importance of being able to incorporate concurrency in a wide variety of application categories.

In this article we are evaluting a new approach to the concurrency.
In the last five years computers are becoming even more parallel.
Intel is pushing multi-core achiteture also on commodity personal computers.
Neverless the computing power is ofter not well used: one again, hardware is a step head of our day-by-day software development.
Remember when the 80286 came into light.
The 286 was able to provide a multi-programming architecture but without memory management protection.
We had to wait 386 hardware to see software working on preemptive multi-tasking, because software cannot cope with unprotected memory. In one word, it costs too much to develop a operating system without the new features the 80386 bring to us.
What about concurrent programming? Can we look similarities in the  concurrency field?

[Read more →]

Working for a very big customer, I found a very nasty interaction between Sun HttpClient (JDK 1.4) and Http  Load Balancers.

In a complex network environment, sometimes you can experience low level TCP/IP comunication errors, because sometimes HttpClient get confused and hangs.

The bad behavior of Sun HttpClient is well known: some guys suggested me to use the Axis Web Client. Anyway you can solve the issue adding these three parameters to the JVM launch line

-Dsun.net.client.defaultConnectTimeout=5000
-Dsun.net.client.defaultReadTimeout=5000
-Dhttp.keepAlive=false

The first two parameters set globally the socket timeout to 5 seconds.
The last parameter forces the JVM to avoid reusing http connections when doing http request.

To be honest, http.keepAlive=false is not always effective and could have huge performance impacts, so be very carful adopting it.

But if you stick on the two sun.net.client.default*  properties (doing some tests) you can solve the issue.

References

From Java Plug-in Control Panel:

[...]
Networking properties description:

sun.net.client.defaultConnectTimeout

sun.net.client.defaultReadTimeout

These properties specify, respectively, the default connect and read timeout values for the protocol handlers used by java.net.URLConnection. The default values set by the protocol handlers is -1, which means there is no timeout set.

sun.net.client.defaultConnectTimeout specifies the timeout (in milliseconds) to establish the connection to the host. For example, for http connections it is the timeout when establishing the connection to the http server. For ftp connections it is the timeout when establishing the connection to ftp servers.

sun.net.client.defaultReadTimeout specifies the timeout (in milliseconds) when reading from an input stream when a connection is established to a resource.

For the official description of these properties, see Networking Properties.

[...]