[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[IDV #MLQ-419928]: ehcache in XmlEncoder
- Subject: [IDV #MLQ-419928]: ehcache in XmlEncoder
- Date: Mon, 24 Aug 2015 13:10:30 -0600
Don,
More below,
> Julien/Yuan-
>
> We we are trying to upgrade RAMADDA to use TDS 4.6. It looks like they
> got rid of the ehcache stuff which is used by XmlEncoder. It looks like
> you've added this to external.jar, but RAMADDA doesn't use that. So, we
> have a couple of questions:
Indeed we used to get it "for free" via ncidv.jar, but no longer. As a
consequence, it is somewhat annoying to have this heavyweight dependency lurking
around. Moreover, I think ehcache has fallen by the wayside. (Ehcache would also
expose this underlying bug in Java 7 on DHCP networks which was another annoying
problem though that is behind us now.)
> - Why is the cache used in XmlEncoder?
As I recall, XML deserialization would ask for the same information over and
over again, so pulling info out of cache instead of reconstructing objects from
scratch ameliorated performance somewhat.
> Does it make that much of a performance difference?
Beyond any effects at IDV start up, probably not, but at the time IDV
performance was in the spotlight so we were making a full-court press.
> - Jeff pointed out that if the ehcache.xml file doesn't exist, then the
> static initialization will fail.
> - What is TDS 4.6 using for it's cache now?
I think they may use Guava Caching (I am trying to confirm this) which is a much
better solution anyway.
> If this is needed, can that be used?
> This is causing an error at RAMADDA startup, so we're trying to avoid this.
In short, this issue is a good candidate for refactoring in the near-term.
> Thanks.
>
> Don
> --
> Don Murray
> NOAA/ESRL/PSD and CU-CIRES
> 303-497-3596
> http://www.esrl.noaa.gov/psd/people/don.murray/
>
>
Ticket Details
===================
Ticket ID: MLQ-419928
Department: Support IDV
Priority: Normal
Status: Open