Thanks Howard!
Unortunately we need some time to migrate to 5.2.x and we face this
issues each day, thus loosing our cluster and shop-customers. Downtimes
each day because of this issue is, well, ugly to horrible depending on
whom you ask...
Unfortunately we depend on "core" library mappings in our current
version like "configuration.add(new LibraryMapping("core",
"x.y.z.core"));" which failed in 5.2, therefore migration means more
than switching a version or jar to us.
Is there any workaround or quickfix we can go for immediately to buy us
time to allow proper migration from 5.1.0.5?
Any hint is highly appreciated
Jens
Am 22.09.11 17:52, schrieb Howard Lewis Ship:
This is known and fixed in 5.2.
On Thu, Sep 22, 2011 at 3:36 AM, Jens Breitenstein<mailingl...@j-b-s.de> wrote:
Hi All!
It seems we encountered a serious concurrency bug in Tapestry 5.1> under
high load.
In our special case one thread was blocked and unable to respond and write
an asset output stream.
As virtual assets are shared and the same ByteArrayOutputStream is reused
for the same asset accross multiple threads, the one thread hanging causes
all other threads which use the same asset to be blocked too. This happens
because ByteArrayOutputStream.writeTo uses synchronized internally. To our
personal opinion we should only cache the data but not the
ByteArrayOutputStream instances.
Any idea how to solve this or am I wrong?
Jens
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
