[Building Sakai] Sakai Time locking

[Raymond Naseef]

One solution for such cases, as with SimpleDateFormat, is to create
instances using ThreadLocal.  Then there can be only 1 instance per thread,
and that would not be a huge amount, and there is absolutely no need to
synchronize them.

-Ray


On Mon, Jul 15, 2013 at 5:32 PM, Steve Swinsburg
<steve.swinsburg at gmail.com>wrote:

> I would +1000 TimeService and Time to die as I have had issues with it as
> well.
>
> The problem is that there are a lot of the older type tools that still use
> it, and that interconnect, so would need to be carefully updated.
>
> cheers,
> Steve
>
>
> On 16/07/2013, at 1:11 AM, David Horwitz <David.Horwitz at uct.ac.za> wrote:
>
>  Hi All,
>
> Digging into some performance behaviour were seeing a number of blocked
> threads creating Time objects:
>
> ajp-bio-8009-exec-2872" daemon prio=10 tid=0x00007fb79e6ff800 nid=0x744c
> waiting for monitor entry [0x00007fb771b32000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at org.sakaiproject.time.impl.MyTime.<init>(MyTime.java:67)
> - waiting to lock <0x00000007cd4fed90> (a java.text.SimpleDateFormat)
> at
> org.sakaiproject.time.impl.BasicTimeService.newTimeGmt(BasicTimeService.java:257)
>
> at
> org.sakaiproject.message.impl.BaseMessageService$BaseMessageHeaderEdit.<init>(BaseMessageService.java:4067
>
>
> The code this relates to is the synchronize block:
>
> public MyTime(BasicTimeService timeService, String str)
> {
> this.timeService = timeService;
> // use formatter A: yyyyMMddHHmmssSSS
> Date d = null;
> synchronized (timeService.M_fmtA)
> {
> ParsePosition pos = new ParsePosition(0);
> d = timeService.M_fmtA.parse(str, pos);
> }
> m_millisecondsSince = d.getTime();
> }
>
>
> Presumably this is synchonized as DateFormats are not thread safe. This
> seems to strengthen the case for a more aggressive removal of the Sakai
> Time object in favour or java.util.Date or joda-time, as we don't see how
> this could be have good performance characteristics.
>
> Any differing views? ;-)
>
> D
> ------------------------------
> UNIVERSITY OF CAPE TOWN
>
> This e-mail is subject to the UCT ICT policies and e-mail disclaimer
> published on our website at
> http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27
> 21 650 9111. This e-mail is intended only for the person(s) to whom it is
> addressed. If the e-mail has reached you in error, please notify the
> author. If you are not the intended recipient of the e-mail you may not
> use, disclose, copy, redirect or print the content. If this e-mail is not
> related to the business of UCT it is sent by the sender in the sender's
> individual capacity.
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to
> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
>
>
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to
> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20130715/15e84de1/attachment.html