saving metric snaps seperately

2 views
Skip to first unread message

Jason Priem

unread,
May 14, 2012, 5:29:49 PM5/14/12
to total-im...@googlegroups.com
Kevin,
It looks like we're currently handling the metric update concurrency problem by applying a global lock to the item...I don't see anything in there saving metricSnaps separately, unless I'm missing them. I'm guessing you just ran out of time to to this? If so, no big problem...if it works now (and it seems to), that can just be for a refactor down the road. If you ran into reasons the separate metricSnap was no good, it'd be great to hear them so we don't go to far down an unproductive road later.
j

--
Jason Priem
UNC Royster Scholar
School of Information and Library Science
University of North Carolina at Chapel Hill

Kevin Campbell

unread,
May 16, 2012, 12:28:34 AM5/16/12
to total-im...@googlegroups.com
On Mon, May 14, 2012 at 10:29 PM, Jason Priem <j...@jasonpriem.org> wrote:
Kevin,
It looks like we're currently handling the metric update concurrency problem by applying a global lock to the item...I don't see anything in there saving metricSnaps separately, unless I'm missing them. I'm guessing you just ran out of time to to this? If so, no big problem...if it works now (and it seems to), that can just be for a refactor down the road. If you ran into reasons the separate metricSnap was no good, it'd be great to hear them so we don't go to far down an unproductive road later.

No, the metric snaps are still needing finished, as are the fully in-memory queues. Currently we're still doing the metrics via vouch.
Sorry, time has been biting me; I'd hoped to get those out by Monday morning. Should have these over shortly.

K



Jason Priem

unread,
May 16, 2012, 6:55:25 AM5/16/12
to total-im...@googlegroups.com
No worries. Since we are running out of time, let's just let the metric snaps slip for this sprint, since there was some question whether it was the best course anyway. The item level locking seems to be working just fine for now and heather and I are both happy with it. We can always add em later if we run into performance problems.

The all-memory queues, on the other hand, seem still important to me. And would be great to have finished. 

Sent from my telephone
--
You received this message because you are subscribed to the Google Groups "total-impact-dev" group.
To post to this group, send email to total-im...@googlegroups.com.
To unsubscribe from this group, send email to total-impact-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/total-impact-dev?hl=en.

Heather Piwowar

unread,
May 16, 2012, 11:53:35 PM5/16/12
to total-im...@googlegroups.com
yup: I'm not convinced that saving the metrics snaps separately is a great idea, so Kevin please do not implement at this point.

Actually, since our call isn't till Tuesday, let me make this chance to clearly suggest what we could still consider on deck and what we should not consider on deck.

Kevin, if you could finish the in-memory queues that would be awesome.  Also, if you could clearly document the best-practice way to install ti on a production server, we'd be golden.

There are a few other things that had been on your plate, but please take them off, since we are pretty much out of CL time  :)  Please don't do saving metric snaps separately, or refactoring of the load tests.  The latter is something I can do based on the functional test version I've been working on.  I think that was it, let us know if you had plans to wrap up anything else.

Sound good?

Heather

Jason Priem

unread,
May 17, 2012, 1:05:10 AM5/17/12
to total-im...@googlegroups.com
Adding my plus one to Heather below. Kevin, you've done epic work on this so far. Thanks so much. I'm really excited about where we're finishing with Jean-Claude... so much improvement.

Sent from my iPad

Kevin Campbell

unread,
May 17, 2012, 5:41:17 AM5/17/12
to total-im...@googlegroups.com
On Thu, May 17, 2012 at 4:53 AM, Heather Piwowar <hpiw...@gmail.com> wrote:
yup: I'm not convinced that saving the metrics snaps separately is a great idea, so Kevin please do not implement at this point.

Actually, since our call isn't till Tuesday, let me make this chance to clearly suggest what we could still consider on deck and what we should not consider on deck.

Kevin, if you could finish the in-memory queues that would be awesome.  Also, if you could clearly document the best-practice way to install ti on a production server, we'd be golden.

There are a few other things that had been on your plate, but please take them off, since we are pretty much out of CL time  :)  Please don't do saving metric snaps separately, or refactoring of the load tests.  The latter is something I can do based on the functional test version I've been working on.  I think that was it, let us know if you had plans to wrap up anything else.

Sound good?

That sounds fine. Don't worry, I am watching my time on this.

I'll write a note on deployment and send that over.

K
Reply all
Reply to author
Forward
0 new messages