Batik will crash when updating due to concurrent modification exceptions in Sun's HashMap class. Rather than describe this in detail (it happens in a number of different sequences of events) I think its enough to say that the exceptions are thrown as a result of AWT thread doing a resize, at the same time as batik's quque is processing something queued by invokeLater. Both threads cause an SVG document update, which causes the concurrent modification exception in the hash map. I've come across this type of problem before in hugely muti-threaded serer system, and the easiest way to fix it was to write a new HashMap class. My new HashMap is fast, and its only synchronised where it absolutely needs to be. It is completely thread safe - no concurrent modification problems, and no blocking thread contentions. I'm modifying my copy of Batic sources so that it uses my HashMap rather than any other HashMap or HashTable classes (Suns's or Batik's).
Can I put these changes in to Batik's source code? (My boss has agreed readily that it is to our advantage, and we are not wanting to hold on to copyright of this HashMap class.) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
