In message <[EMAIL PROTECTED] m>, "Karachiwala, Aslam" writes: >I've seen a couple of mentions of this on the list but no explanation or >workaround. My web app uses ORO to modify query string params of
Please try using the the latest release. There have been one or two fixes since 2.0.4 that could be related. On the other hand, even though you are compiling patterns with READ_ONLY_MASK and using a single compiler and matcher instance per class instance, if the compiler or matcher is accessed concurrently, you'll wind up with random errors. In fact, there's no point in compiling the pattern in findPattern with READ_ONLY_MASK if its lifetime does not exceed the scope of the method. If findPattern is accessed concurrently, then the matcher access must be put in a critical section. Assuming your program has multiple threads invoking findPattern on a single object, I'd suggest dedicating a separate InsRegExpProcessor per thread. The general rule is that you want to use a separate matcher per thread to avoid the potential complexity of concurrency control and synchronization overhead. On a second read of your email I see the exception in question is thrown in the compile() call. That would only happen if you're accessing it concurrently. The method is completely deterministic and compiling the same pattern will always produce the same result (either it will succeed or fail). It will not sometimes succeed and sometimes fail. daniel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
