user10916752 wrote:In anticipation of it being a formatting issue, I'd start by doing research into whatever Formatters, DecimalFormats, Locales, etc. are used between where you call System.out.println(35.5) and where the sequence of characters actually gets sent down the stream, and in particular, any of them that are "system-wide" or otherwise shared by common output or formatting classes. For instance, any call to Locale.setDefault() would be a major red flag here. Then you can use grep or your IDE to search for calls that could modify which one is used or how it behaves. If you don't have source code for everything, you may have to consider attaching a debugger to one or more systems with a tracepoint set on these calls.
The problem that I am having is that I don't know where to begin to look. We have 13 servers in a farm with 5 core applications running, a couple of thousand application options, thousands of users. Three different servers had the problem in the last month.
jschell wrote:He did say he observed the behavior on 3 servers, so a hardware problem seems unlikely. Unless those servers' CPUs happened to roll off the assembly line in the same batch and happened to have the same defect out the door.
Just as a thought...
CPUs these days have floating point processors.
What happens when one of those becomes flaky (on its way to failure) in terms of formatted output?
GBru wrote:It isn't in the VM nor the Java API - in general.
At this point I can only deduce that the failure is either in FormattingDecimal or the JVM.
GBru wrote:Is there perhaps another FloatingDecimal class floating around somewher? Not the one from sun.misc? Or maybe from an older version of Java that didn't get completely cleaned up? Or one that somebody wrote or modified himself? Maybe that is getting picked up on some classpath ahead of the real one in some cases?
An update on this item....
We continue to have this problem. This a critical problem. When the problem happens, client data is corrupted. We do have an alert in place to let us know as soon as it happens, but it continues to be a big problem.
We are running java 1.6.0_07 and tomcat 5.5 and are moving toward upgrading to Java 7 and Tomcat 7. Maybe this will fix the problem.
I have a floattest.jsp that has the following code:
<%=new FloatingDecimal(3.25 ).toJavaFormatString()%>
When the corruption occurs, this produces the result of 3.0. It should be 3.25.
All doubles being processed when corruption happens are wrong at this point. Floats are ok.
The last time that this happened, I got the source code for FloatingDecimal and embbeded it in my floattest.jsp.
A call to the embbed source version produced the correct number 3.25. The call to the original loaded class FloatingDecimal produced 3.0.
Both in the same jsp, producing different results.
EJP wrote:He's not using it (directly) in his real code. He saw that the normal double formatting was using it under the covers. Then he put a direct call to it in his code, and put a call to inline code copied from that class into his code as well. At first things seem to be fine, then, at some point, using that class the way normal double formatting does produced the rounded value, while executing the inline code continued to produce the correct value. (At least, that's how I interpreted his comments.) This leads me to believe a corrupt version of the class is getting loaded at some point.sun.misc.FloatingDecimalIf that's the case he shouldn't be using it at all.