[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Subclipse-users] Number Format Exception with show history

From: Mark Phippard <markphip_at_gmail.com>
Date: Fri, 26 Apr 2013 14:35:30 -0400

I believe you are right and this is a thread issue. I will see if I
can fix core Subversion for 1.8 but you should implement the change of
catching Exception as an interim fix.

Mark

On Fri, Apr 26, 2013 at 11:30 AM, Stephen Elsemore <selsemore_at_collab.net> wrote:
> Scattered thoughts on this:
>
> According to the javadoc, SimpleDateFormat.parse throws only ParseException, but as the stacktrace shows it is throwing NumberFormatException in this case. So, in a sense, this is problem at the Java level. But it could probably be handled at the JavaHL level.
>
> org.apache.subversion.javahl.types.LogDate takes a date String in the constructor and tries to parse it into a Date. But, before doing that, it does a basic preliminary check to see if the date String is validly formatted:
>
> if (datestr == null || datestr.length() != 27 || datestr.charAt(26) != 'Z')
> {
> throw new ParseException("String is not a valid Subversion date", 0);
> }
>
> Apparently this check passes, since a ParseException is not thrown. Although it's possible that the date String is still not properly formatted, it seems unlikely. This makes me suspect that this could be a threading issue. There are all kinds of warnings about SimpleDateFormat not being thread safe, and that a single SimpleDateFormat instance should not be used by multiple threads without proper synchronization. But this is what LogDate does:
>
> private static final DateFormat formatter = new SimpleDateFormat(
> "yyyy-MM-dd'T'HH:mm:ss.SSS z");
>
> And in constructor:
>
> Date date = formatter.parse(datestr.substring(0, 23) + " UTC");
>
> I'm not sure offhand if/when/where Subclipse might get log messages from multiple threads, but it's certainly reasonable that Subclipse or some other consumer might do this, so LogDate should be thread safe. Maybe something like this:
>
> Date date;
> synchronized (formatter) {
> date = formatter.parse(datestr.substring(0, 23) + " UTC");
> }
>
> Probably it wouldn't hurt to throw a try/catch around the parse as well, in case for whatever reason the date String is truly formatted incorrectly.
>
> The org.tigris.subversion.svnclientadapter.javahl.JhlLogMessage constructor does wrap the LogDate creation with a try/catch:
>
> try {
> logDate = new LogDate(new String(this.revprops.get(DATE)));
> } catch (ParseException e) {
> }
>
> Since nothing is being done with the exception anyway, it probably wouldn't hurt to catch Exception rather than ParseException to prevent unexpected errors (like NumberFormatException) from going any further (this fix can be made at the Subclipse level). This would result in logDate being null, but JhlLogMessage.getDate() looks like this:
>
> public Date getDate() {
> if (logDate == null)
> return new Date(0L);
> return logDate.getDate();
> }
>
> Which means that a date that was actually formatted incorrectly would ultimately show up in the history view and other places that show log dates as something like "12/31/69 4:00pm", rather than "Not Available" (which is what the history view will show if an actual null date is returned. This isn't ideal, but I'd be reluctant to change the getDate() method because it would take some effort to determine if all callers properly handle a null date being returned (probably not, since this code was written this way in the first place).
>
>> -----Original Message-----
>> From: spennec [mailto:sebastien_at_pennec.ch]
>> Sent: Friday, April 26, 2013 4:37 AM
>> To: users_at_subclipse.tigris.org
>> Subject: Re: [Subclipse-users] Number Format Exception with show history
>>
>> jcompagner,
>>
>> Based on the stacktrace, could the problem be caused by a log message (i.e.
>> commit message?) when retrieving the data from SVN?
>>
>> The fact that the problem occurs after a reboot could be explained by a cache
>> being invalidated?
>>
>> Anyway, I'm also impacted by this problem and would love to see a solution,
>> or help you find one :)
>>
>> Sébastien
>>
>>
>>
>> --
>> View this message in context: http://tigris-
>> scm.10930.n7.nabble.com/Number-Format-Exception-with-show-history-
>> tp93040p93120.html
>> Sent from the subclipse - users mailing list archive at Nabble.com.
>>
>> ------------------------------------------------------
>> http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessag
>> eId=3054370
>>
>> To unsubscribe from this discussion, e-mail: [users-
>> unsubscribe_at_subclipse.tigris.org].
>
> ------------------------------------------------------
> http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=3054401
>
> To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=3054403
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].
Received on 2013-04-26 20:35:36 CEST

This is an archived mail posted to the Subclipse Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.