Women in Technology

Article:		Scaling Enterprise Java on 64-bit Multi-Core X86-Based Servers
Subject:		No really reasonable suggestion
Date:		2006-11-03 15:20:48
From:		kutzi
Sorry, but I think that some of your suggestions are not very reasonable. Examples: - "You should [..] upgrade older applications to use the concurrency, NIO, and logging APIs whenever possible." So you are suggesting changing old, perfectly running application to the new concurrency utils and NIO without any hard fact that the current implementation is to slow? And even more important: the new implementation would be substantial better? - "If the system runs lengthy full GC very frequently, you probably have a memory leak somewhere in your application." No, that would more probably mean that allocate too much unneeded objects. A memory leak could be indicated, if the heap usage directly after a Full GC is going constantly up - "Most Java EE application servers have not completely evolved their code base to take advantage of JDK 5.0 APIs, especially the concurrent utility libraries. In this case, it is crucial to choose an open source application server [..] where you can make changes to the server code." You are really sure, that you want to suggest that average developers should begin to build the new concurrency classes into the application server of their choice?

Showing messages 1 through 2 of 2.

• No really reasonable suggestion
  2006-11-03 20:49:34  Michael Juntao Yuan | [View]
  
  
  Kutzi,
  
  Hmm, first and foremost, I am suggesting developers to take advantage of Java 5.0 APIs in their own applications.
  
  Now, if the application server itself has concurrency issues, I understand that the average application developer would not know how to fix it. But you can at least find the contention point in the source code (in the case of an open source app server) and raise a issue (bug report or feature request) to the open source developers in that community ...
• No really reasonable suggestion
  2006-11-06 05:54:16  kutzi [View]
  
  
  > first and foremost, I am suggesting developers to take advantage of Java 5.0 APIs in their own applications.
  
  Yes, that is certainly a good thing to do, but not "whenever possible" as you said, but only if the gains outweigh the risks. E.g. util.concuurent.Locks are faster than synchronized blocks, but they bear the additional risk of forgetting to release it. And, as Goetz says in Java Concurrency in practice, perfomance is a moving target. While Locks used to be much faster than synchronized, in Java 6 the gap has nearly closed.