Re: ECS Deep Bug

[Robert Burrell Donkin <ro...@blueyonder.co.uk>]

On Tue, 2008-05-27 at 15:06 +0200, Mauro Manfrin wrote:
> Hello,

hello mauro

sorry for the late reply (i know it's no excuse but i've been
exceptionally busy)

> I'm contacting you to notify a Deep Bug I found on ECS project.
> 
> First of all, I want to tell you that my company and I, use ECS1.4.1 and 
> then 1.4.2 as a kernel library for HTML page construction.
> We use Ecs as a sort of base toolkit for our framework that's the base for 
> our CRM solutions.
> Nowaday, I think that more than 10000 telephone operators use our ecs based 
> solution, 8 hours a day, in contact center applications. That's a real test 
> environment.
> 
> Well. In the last installation, we used ecs on an AIX RISC JDK 1.5 platform 
> and we found a strange bug.
> I think that that bug affects all releases of ECS, because of a base mistake 
> in ConcreteElement.java class.
> 
> Let's go to the real problem:
> The class ConcreteElement exposes a method
> addElement(Element element)
> that calls
> addElementToRegistry(Integer.toString(element.hashCode()),element);
> so it gives a key valued element.hashCode() to that element.
> That's the point: element.hashCode() can't be a unique key because sometimes 
> we can have two elements with the same hasocode.
> We experienced it only on IBM JDK, but the sun documentation (javadoc) 
> states:
> 
> "It is not required that if two objects are unequal according to the 
> equals(java.lang.Object) method, then calling the hashCode method on each of 
> the two objects must produce distinct integer results. However, the 
> programmer should be aware that producing distinct integer results for 
> unequal objects may improve the performance of hashtables."
> 
> So sometimes, two different objects can have the same hashCode!
> So, sometimes two calls to addElement(element) can result in only the second 
> object stored in the ConcreteElement.
> So sometimes, on out instalaltion some table rows misses, or some row cells 
> misses or...
> 
> I think that's happening when IBM garbage collector compacts the heap, so 
> that a new object can get same address (i.e. hashcode) of an old shifted 
> object.

interesting

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6321873 (for example)
suggests that this problem would not be limited just to AIX

> I've done some fixes to resolve.
> I've done a version of ConcreteElement that sotores object in the Map only 
> if you give explicitly a key-name, otherwise it stores only in the Vector. 
> That seems to work good, with a good retro-compatibility.

that sounds like it would work

> I know that ECS is not in a work-inprogress state, but why don't give to the 
> posterity a bugless software?

would you consider donating your patch to Apache?

- robert



---------------------------------------------------------------------
To unsubscribe, e-mail: ecs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: ecs-dev-help@jakarta.apache.org

Re: ECS Deep Bug

[Robert Burrell Donkin <rd...@apache.org>]

On Tue, 2008-06-24 at 18:09 +0200, Mauro Manfrin wrote:
> Sure, I'm glad to submit you my patches.
> I prepared a zip file with the patches
> (but how can I give it to you?).

i've created a project in JIRA:
https://issues.apache.org/jira/browse/ECS please create an issue and
attach your patch

> I modified classes since the jakarta ECS SVN repository.
> You will find the ConcreteElement class, and subsequent 5 classes adaptions.
> Pay attention, these patches are based on the trunk, not the 1.4.2 version.
> 
> What are you planning? A new release? A simple trunk commit?

a simple commit will be the first stage

once you've confirmed the first works, i'll look into creating a
release 

> I benefit on these contact, for submitting you another very simple
> evolution, really usefull for adoption of ecs in frameworks.
> ECSDefaults can be configured only statically from a properties file, not
> dinamically.
> I think this is a purposeless.
> But some features like CaseType, Codeset and most of all PrettyPrinting are
> often needed to be changed dinamically
> (for example in webapp lifecycle, switching from a test to a production
> state).
> So I propose you a very simple evolution of ECSDefaults class, exposing 3
> methods to change these default property values.
> (how can I send you this version?)

create aPatch ;-)

(and submit using JIRA)

- robet