IBM releases Java 5 SDK for Windows with the J9 JVM

It’s bundled in “The IBM Development Package for Eclipse”

The obligatory “java -version” :

C:ibm_eclipseibm_sdk50>jrebinjava -version
java version “1.5.0”
Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20051104)
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223-20051103 (JIT enabled)
J9VM – 20051027_03723_lHdSMR
JITÂ – 20051027_1437_r8
GCÂ Â – 20051020_AA)
JCLÂ – 20051102

Financial news — Wily acquired by CA, Mecury Interactive delisted from NASDAQ for failing to fulfill SEC filing requirements on time

alarm:clock: CA Buys Wily for $375M And Other Fresh Deals

BRISBANE, CA Computer Associates (NYSE: CA) To Acquire Wily Technology For $375M in Cash. Wily Has Raised Nearly $60M in VC Funding Since 1998 from Accel Partners, Focus Ventures, Greylock and Peninsula Capital Partners.

alarm:clock: Quokka Sports Founder Cashes In Again

It appears that Wily has had $72M in revenues in the past 12 months, so $375M in cash is a sweet multiple.


Mercury Interactive shares to be delisted from Nasdaq

Mercury Interactive has been de-listed from Nasdaq due to a filing delay. Mercury Interactive’s troubles following the recent resignations of three senior executives are not over. The company has now been de-listed from Nasdaq having failed to fulfill SEC filing requirements on time.

Mercury’s share price has seen a drop of 20% at the point of de-listing, with financial analysts indicating that, should these problems persist, the company’s market-leading position in software testing tools would make it an attractive acquisition target.

How Google uses Berkeley DB HA for user authentication… a case study.

This case study gives a high level overview of Google’s setup for user authentication, interesting read.

… user authentication is a transactional event that requires fast, reliable, scalable, persistence and robust high-availability. To deliver this level of service, Google Accounts uses Berkeley DB HA for the storage and retrieval of user data and for replication, thereby ensuring scalability and availability.

Web Performance, Inc. reports on Tomcat Performance : Windows vs. Linux

Servlet Performance Report: Comparing Tomcat Performance Across Platforms

Prior to reaching capacity, our Linux server showed it’s ability to scale subtly better, notably with a higher completed response rate. This trend arises again after the servers have been able to recover from their performance slump.

When our servlet found itself hitting memory limits of the app server, the platforms had an opportunity to reveal different error handling techniques. Linux maintained it’s lead over it’s Windows counterpart, except when it was forced to deal with the memory shortage. Users were potentially forced to wait minutes or more for their page to complete loading. Potential waits turned into repeated waits for users navigating through a long sequence of pages. Windows users saw a different story. Under the same memory shortage, the OS was forced to turn away traffic, but delivered roughly the same number of successful hits as our Linux server.

Intel paper: Performance Scalability of Data-Mining Workloads in Bioinformatics

Performance Scalability of Data-Mining Workloads in Bioinformatics, from Intel – White Papers, Webcasts, and Case Studies – ITPapers

Data mining is the extraction of hidden predictive information from large data bases. Emerging data mining applications are important factors to drive the architecture of future microprocessors. This paper analyzes the performance scalability on parallel architectures of such applications to understand how to best architect the next generation of microprocessors that will have many CPU cores on chip.

On sforce’s performance and scalability …

Simon Fell > Its just code > Share and Enjoy

a completely new SOAP stack …  was written from the ground up purely to be Salesforces server side soap processor, its is extensible just enough to do its job and no more (many soap tools are extremely extensible, and it comes at a considerable cost), we concentrated hard on perf both response time and scalability. The open source soap stack that we used previously has particularly bad scalability issues, it uses a lot of memory to process a request, which leads to a high level of GC related load, and a reduced concurrency ability from transient out of memory exceptions. Reduced GC load is good for us, and improved response times are good for you, in some testing I did I saw response times (for the entire request not just the soap processing part) as much as 50% faster than the earlier stack.