I finally found the source of my problems, actually two sources: - ThreadLocal entries too high. - BufferedCoordinateOperationFactory internal pool.
The problem with ThreadLocal's, which were growing to hundreds of thousands of entries in less than an hour, was corrected by doing a call to "CRS.cleanupThreadLocals() " at the end of each map generation transaction. The problem (for my needs) in BufferedCoordinateOperationFactory was a huge cache of CoordinateOperations. The cache, a SoftValueHashMap<CRSPair, CoordinateOperation>, does not have a top limit and relies on the GC to clean up unused entries. For my needs, I need to create a new CRS for each new set of coordinates and each one counts as a different CRS to the cache, which is saved and never needed again in my workflow. Basically, I don't need the cache. The two options I am evaluating is to either create an extension of BufferedCoordinateOperationFactory or use DefaultCoordinateOperationFactory, which does not have the pool. So far I am using the later and, although performance of my application was affected by about 9% in response time, it is completely stable. -Felipe NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ------------------------------------------------------------------------------ _______________________________________________ GeoTools-GT2-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
