Am Dienstag, den 30.05.2006, 20:33 +0200 schrieb Stefano Bagnara: > We're probably misunderstading something. > > Does the "O => i" change fix JAMES-512 ? > Or we need anyway the full removal of the cache?? > > I understood that we need the removal of the cache, but maybe I didn't > understand your tests. > > I was under the impression that the leak is only fixed removing the 2 > hashmaps usage. > > Btw I don't care about the discussion issue: I think I already helped > giving my support to this bug. > > Now you can discuss how much you like ;-) > > I will reply when I think I can add technical value to the discussion > given my knowledge of the codebase. > > If you want to write unit tests for this bug I suggest to start from > testing racing conditions between dispose and remove: > String key = mail.getName(); > mail.dispose(); > repository.remove(mail.getName()); > And viceversa. > Imho the caches could have been written for something related to this usage. >
Yeah please add junit test for that! That will really help to understand what is going on. > I'm sorry for my "too radical diagnosis": I will try to keep my comments > much more on a technical level. Btw I commented that because I > understood that you were testing the "patched" version and I didn't > understood why you was trying to fix the code that was just been > removed. Btw I understood you're trying different ways. > > From a technical point I don't think that we should keep a cache if it > is never useful/used in James codebase just to avoid destabilisation. > > Stefano you right Stefano why whe should keep it if its not usefull for us! > Bernd Fondermann wrote: > > Stefano Bagnara wrote: > >> > >> If you look in the svn history of that file you will see that there > >> was much worst bug about this. Maybe this was neven called anyway > >> because the streams were always correctly closed by James. > > > > In fact, currently it gets called. I checked with a debugger and we > > notice it from the change in behavior as we change the code. > > > >> Imho, the fact that it is (and has been) so buggy is a +1 to remove it > >> and eventually investigate bugs introduced removing that outdated code > >> instead of loosing much more time fixing that code itself. > > > > Again, this is a much too radical diagnosis for me (although in the end > > it might happen that the whole stuff gets rewritten. but it is not > > obvious to me at this point in time). But we know this discussion > > already... ;-) > > I don't understand this whole reasoning behind 'loosing time', > > 'discussing too much', 'risk'. > > I'd rather understand what's really happening, writing test and all this > > old-fashioned stuff and resolve the problem step-by-step. > > > > Bernd bye Norman
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
