Hi,
You can replace default VirtualAssetStreamer with your implementation by
contributing it to ServiceOverride (contributeServiceOverride). Your version
of VirtualAssetStreamer can be based on
existing org.apache.tapestry5.internal.services.VirtualAssetStreamerImpl,
just replace all references of ByteArrayOutputStream to your class that
extends ByteArrayOutputStream but has not synchronized writeTo().
Another that does not require application change is to deploy a caching
proxy to cache just assets.
Best regards,
Cezary
On Wed, Sep 28, 2011 at 1:00 PM, Jens Breitenstein <mailingl...@j-b-s.de>wrote:
> 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<mailinglist@j-b-**s.de<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-unsubscribe@tapestry.**apache.org<users-unsubscr...@tapestry.apache.org>
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
