gpoul's Out Of Memory Blog

IBM will discontinue support for WebSphere Application Server V6.1 effective September 30, 2012. Please plan your migrations accordingly. You can find more details in the announcement letter.

Please be aware that the JDK shipped with IBM WebSphere Application Server Versions 7.0 through 7.0.0.13, 6.1 through 6.1.0.35, and 6.0 through 6.0.2.43, for Distributed, i5/OS and z/OS operating systems has a serious denial of service security exposure. When converting “2.2250738585072012e-308″ to a binary floating-point number this vulnerability can cause the Java Runtime Environment to go into a hang, infinite loop, and/or crash resulting in a denial of service exposure.

Information on how to obtain the APARs can be found in our flash alert TN1462019.

This vulnerability is also in Oracle’s JVM, so if you’re using a JVM not shipped by IBM, please refer to CVE-2010-4476.

February 3, 2011: “A critical point in the history of the Internet was reached today with the allocation of the last remaining IPv4 (Internet Protocol version 4) Internet addresses from a central pool. It means the future expansion of the Internet is now dependant on the successful global deployment of the next generation of Internet protocol, called IPv6.” – Available Pool of Unallocated IPv4 Internet Addresses Now Completely Emptied

I’ve never really thought about the backend systems when using my smartphone, but with more and more people using mobile internet devices to access sites the load patterns will be impacted. While during normal operation the load is spread nicely throughout the day, when large events occur sites will be hit by a huge number of clients simultaneously. Billy Newport describes those FlashLoads in his latest blog post.

Using the WS-BPEL 2.0 standard with WebSphere Integration Developer:

The IBM products WebSphere Integration Developer (hereafter called Integration Developer) and WebSphere Process Server (hereafter called Process Server) support the majority of the concepts of WS-BPEL 2.0. However, some of the WS-BPEL language elements in Integration Developer and Process Server Version 7 are still using the syntax defined in the preliminary BPEL4WS 1.1 specification. Many of the language differences are purely related to the WS-BPEL syntax, while the runtime semantics of the affected language elements is identical. For example, in the WS-BPEL 2.0 standard, the switch and terminate activities have been renamed to if/else and exit, respectively, while keeping their semantics exactly the same.

As a result, when business processes are modeled in compliance with the WS-BPEL 2.0 standard, manual rework is necessary before these processes are consumed by Integration Developer and Process Server. To substantially reduce this rework, this article describes an import tool that transforms the affected WS-BPEL 2.0 language elements into semantically equivalent language elements understood by Integration Developer and Process Server V7.

Logging is one of those things that sounds easy, but is incredibly hard and complex to do properly. Especially if you have to debug applications in production it is hard to decide which log entries to have in your code and which ones are too much overhead to include. These 10 Tips for Proper Application Logging are definitely a good resource to start thinking about whether you’re doing it right or where you might be able to improve. [via TSS]

We’ll also have an IBM Software Experience event in Q1 this year. This time we chose to do a PoT on Batch Modernization with Java on February 17. In this one-day workshop you’ll get to know WebSphere Compute Grid and Java-based batch.

If you would like to attend, please complete our registration form on the IBM Software Experience page.

We plan on having additional PoTs throughout the year, so if you have suggestions for topics which might be of interest, please let us know!

Recently I came across a fairly interesting paper about Large-scale Incremental Processing Using Distributed Transactions and Notifications written by two Googlers, Daniel Peng and Frank Dabek. (Proceedings of the 9th USENIX Symposium on Operating Systems Design and Implementation, 2010)

Most of the stuff was interesting, but not applicable to what most people will have to work with, unless you try to work with a massive dataset… like… let’s say building an index of everything on the web.

One of the most interesting parts for me was the following paragraph:

Our experience with thread-per-request was, on the whole, positive: application code is simple, we achieve good utilization on many-core machines, and crash debugging is simplified by meaningful and complete stack traces. We encountered fewer race conditions in application code than we feared. The biggest drawbacks of the approach were scalability issues in the Linux kernel and Google infrastructure related to high thread counts. Our in-house kernel development team was able to deploy fixes to address
the kernel issues.

I’m selling my late 2006 white MacBook with the following specs:

MacBook white Core 2 Duo 2GHz
2GB RAM
80GB HDD
Mac OS X Snow Leopard Box Set incl iLife and iWork
US Keyboard (was replaced in 2009 by the Apple Store in SF)

The price I consider fair is about 250,- EUR. This MacBook was ordered and shipped in December 2006. The battery has been replaced by Apple several times and is still in good condition.

If you’re interested in buying it and live in Vienna or plan on picking up the MacBook in Vienna, please leave a comment below and I’ll get in touch with you.

Anyone who worked with web applications, dealt with web security, or single sign-on will certainly have learned that HTTP cookies, while a simple concept, have many complex intricate behaviors that even differ between browser implementations. What’s making things worse is that there is no real written specification that documents the design behavior. In his recent post on HTTP cookies and protocol design Michal Zalewski outlines many of these intricacies and design behaviors and I’m sure you’ll learn about a few you haven’t seen before ;-)