[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tapestry-user
Subject:    Re: Load test with Tapestry 5.3.4-rc-7 and subtile bug/problem with ResourceStreamerImpl/ResourceCha
From:       Howard Lewis Ship <hlship () gmail ! com>
Date:       2012-06-29 1:26:09
Message-ID: CACd-vsOys=RT6wD_4zH68vDT=qq5eeb+nq_V_NNTxQCAnd8PfA () mail ! gmail ! com
[Download RAW message or body]


https://issues.apache.org/jira/browse/TAP5-1964

On Thu, Jun 28, 2012 at 6:22 PM, Howard Lewis Ship <hlship@gmail.com> wrote:

> Ah, reading back, I see exactly what Robert's getting at: the placeholder
> value, used in production, should be limited to one-second precision. This
> represents a change in 5.3 to ditch all the code that checks for changes:
> literally, the filter responsible is not instantiated in production mode,
> and several other services related to propagating events, become no-op
> placeholders.
>
>
> On Thu, Jun 28, 2012 at 6:20 PM, Howard Lewis Ship <hlship@gmail.com>wrote:
>
>> Robert is right on this one; there's code elsewhere to uses the
>> URLChangeTracker (the core of ResourceChangeTracker) at second (not
>> millisecond) precision, for this exact scenario ...  I suspect something is
>> slightly out of wack for it to come back as it has.
>>
>>
>> On Thu, Jun 28, 2012 at 4:43 PM, Robert Lentz <robert@teksolv.de> wrote:
>>
>>> Hi Thiago,
>>>
>>> well I don't have jetty available atm, but how would jetty or any other
>>> java date parser parse a string date including seconds but without
>>> milliseconds provided to a long milliseconds value
>>>
>>> If-Modified-Since Thu, 28 Jun 2012 22:32:41 GMT
>>>
>>>
>>> I assume the millis range 000-999 must be ignored and the long will
>>> always ends with "000". Anything else is random - right?
>>>
>>> Aloha
>>>  Robert
>>>
>>> Thiago H de Paula Figueiredo schrieb:
>>> > On Thu, 28 Jun 2012 19:38:52 -0300, Robert Lentz <robert@teksolv.de>
>>> > wrote:
>>> >
>>> >> Hi All,
>>> >
>>> > Hi!
>>> >
>>> >> The header "If-Modified-Since " which will be parse by Tomcat's
>>> >> FastHttpDateFormat.parseDate(..) method to a long, when called
>>> >> ifModifiedSince = request.getDateHeader(IF_MODIFIED_SINCE_HEADER).
>>> >> During this parsing any milliseconds are ignored/not available,
>>> >
>>> > Isn't this a Tomcat issue instead of a Tapestry one? Of course, we can
>>> > fix in Tapestry's side and that wouldn't be the first time something
>>> > like that happens. Have you tried Jetty to test whether it happens in
>>> > it too?
>>> >
>>> > Your fix sounds harmless enough, so I see no reason for it to be
>>> > integrated in Tapestry itself.
>>> >
>>> > And thank you very much for noticing, investigating and provinding a
>>> > solution! :)
>>> >
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator of Apache Tapestry
>>
>> The source for Tapestry training, mentoring and support. Contact me to
>> learn how I can get you up and productive in Tapestry fast!
>>
>> (971) 678-5210
>> http://howardlewisship.com
>>
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>



-- 
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com


[prev in list] [next in list] [prev in thread] [next in thread]