jasig-cas IRC Logs-2011-08-05
[13:01:55 CDT(-0500)] <wgthom> checking in
[13:02:03 CDT(-0500)] <serac> Hey.
[13:02:07 CDT(-0500)] <wgthom> howdy
[13:02:19 CDT(-0500)] <serac> I will review your exp policy work this weekend.
[13:02:38 CDT(-0500)] <serac> And hopefully follow up on that cas-dev thread.
[13:03:21 CDT(-0500)] <wgthom> cool….did you seem my note about issue with RegistryCleaner and throttling?
[13:03:40 CDT(-0500)] <serac> I did and it will take some code review and consideration to answer. So I need this weekend.
[13:03:58 CDT(-0500)] <serac> Nothing came to mind immediately.
[13:05:27 CDT(-0500)] <serac> WTF does this mean re jasig.org:
[13:05:30 CDT(-0500)] <serac> "We had to shut it down for performance reasons"
[13:05:46 CDT(-0500)] <battags> FishEye is a beast
[13:05:47 CDT(-0500)] <wgthom> where is that?
[13:05:55 CDT(-0500)] <battags> it was affecting performance of the machine
[13:06:03 CDT(-0500)] <battags> since there wasn't enough memory to run all the Atlassian apps
[13:06:04 CDT(-0500)] <serac> FishEye alone?
[13:06:18 CDT(-0500)] <serac> I mean that was the primary resource hog?
[13:06:23 CDT(-0500)] <battags> yeah
[13:06:28 CDT(-0500)] <serac> pffft
[13:06:34 CDT(-0500)] <battags> our subversion repository is pretty messed up
[13:06:43 CDT(-0500)] <wgthom> my understanding is that the uP source history is messing up FE, not FE per se
[13:06:45 CDT(-0500)] <battags> with some uPortal history I think
[13:06:45 CDT(-0500)] <serac> Further evidence FishEye is cool in concept, awful in practice.
[13:07:03 CDT(-0500)] <battags> apparently whatever is up with the uPortal history is just killing FishEye
[13:07:10 CDT(-0500)] <battags> and I don't think Atlassian was ever able to figure out why
[13:07:11 CDT(-0500)] <wgthom> right…not fe issue
[13:07:24 CDT(-0500)] <serac> These are tools that should simply work.
[13:07:33 CDT(-0500)] <wgthom> battags: are you still blocked?
[13:08:19 CDT(-0500)] <battags> with 3.4.9?
[13:08:25 CDT(-0500)] <wgthom> yes
[13:08:36 CDT(-0500)] <battags> no jasig.org came back up
[13:08:42 CDT(-0500)] <battags> so its fine
[13:08:43 CDT(-0500)] <battags> I'm just at work now :-p
[13:09:13 CDT(-0500)] <serac> So the whole enchilada had problems, they fingered FishEye, then shut it down to bring the other stuff back up?
[13:11:07 CDT(-0500)] <wgthom> what's left to be done for 3.4.9 release…I've got cycles this hour….could help move things along.
[13:12:19 CDT(-0500)] <battags> I need to build it
[13:12:23 CDT(-0500)] <battags> and publish it
[13:13:46 CDT(-0500)] <wgthom> is it all automated via mvn?
[13:14:31 CDT(-0500)] <battags> other than the emails and other announcements (and the uploading to the Jasig server), yes
[13:15:19 CDT(-0500)] <wgthom> wan't there a checklist somewere….can't see to locate anything in jasig wiki….
[13:15:28 CDT(-0500)] <battags> yes its in the wiki
[13:15:34 CDT(-0500)] <battags> I think in the CAS space
[13:16:30 CDT(-0500)] <wgthom> searching on 'cas checklist' gives nothing...
[13:17:07 CDT(-0500)] <battags> its called release process
[13:17:07 CDT(-0500)] <battags> https://wiki.jasig.org/display/CAS/Release+Process
[13:17:23 CDT(-0500)] <wgthom> ah thx
[13:18:01 CDT(-0500)] <battags> you can add a checklist label if you want
[13:18:47 CDT(-0500)] <wgthom> cas release checklist publish
[13:18:47 CDT(-0500)] <wgthom> done.
[13:19:49 CDT(-0500)] <battags> the CAS part my be redundant
[13:19:53 CDT(-0500)] <battags> may*
[13:20:03 CDT(-0500)] <wgthom> so, shall we try to step through this now…or do have something to discuss
[13:20:17 CDT(-0500)] <battags> I have to do it from my home computer when I get home
[13:20:28 CDT(-0500)] <wgthom> how come?
[13:20:38 CDT(-0500)] <battags> because I don't have the code on my work machine
[13:21:03 CDT(-0500)] <wgthom> lol
[13:21:24 CDT(-0500)] <wgthom> i was suggesting that I try to step through it…while we are all here.
[13:21:26 CDT(-0500)] <battags> my public/private keys are also on my machine
[13:21:39 CDT(-0500)] <battags> which sign the artifacts
[13:21:49 CDT(-0500)] <battags> giving me complete control... muaahhhhhhhh hahahhaha
[13:21:53 CDT(-0500)] <wgthom> i've got a key
[13:21:54 CDT(-0500)] <serac> haha
[13:21:59 CDT(-0500)] <battags> actually they mostly just ensure that the things are signed
[13:22:23 CDT(-0500)] <serac> Are we really in a hurry here?
[13:22:38 CDT(-0500)] <serac> Seems a good time to talk about a backup release manager.
[13:23:03 CDT(-0500)] <battags> Marvin, are you set up for access?
[13:23:04 CDT(-0500)] <serac> But I don't see the need for it now.
[13:23:05 CDT(-0500)] <wgthom> not so much in a hurray as want to make good use of our time…plus I'm interested in know how to do it
[13:23:17 CDT(-0500)] <serac> Totally understand.
[13:23:26 CDT(-0500)] <serac> battags: no
[13:23:39 CDT(-0500)] <battags> the steps are straightforward. But you make a good point that we need to document the "onboarding of new release engineers"
[13:23:43 CDT(-0500)] <serac> We should delegate a backup and then make sure the backup has the know-how and access.
[13:23:57 CDT(-0500)] <battags> i.e. they need to be in the Jasig WebDav group
[13:23:59 CDT(-0500)] <serac> Again, not that it's needed in this case.
[13:24:01 CDT(-0500)] <battags> they need access to sonatype and a key
[13:24:04 CDT(-0500)] <wgthom> i think all the committers should have that
[13:24:10 CDT(-0500)] <serac> -1
[13:24:23 CDT(-0500)] <serac> Every good project has a primary for release engineers.
[13:24:36 CDT(-0500)] <serac> There's a need for a single backup.
[13:24:39 CDT(-0500)] <wgthom> yes, i'm talking about being able to easily share the load
[13:24:54 CDT(-0500)] <battags> the load of typing in some maven commands?
[13:24:57 CDT(-0500)] <serac> This is the wrong task for sharing the load.
[13:25:00 CDT(-0500)] <wgthom> instead of wasting our time talking about it, i could have done it already this hour
[13:25:14 CDT(-0500)] <battags> I could have done it last night if Jasig was up
[13:25:19 CDT(-0500)] <battags> and we wouldn't even have this conversation
[13:25:22 CDT(-0500)] <battags> :-p
[13:25:40 CDT(-0500)] <serac> Does UP let anyone cut releases?
[13:26:17 CDT(-0500)] <serac> ??
[13:26:17 CDT(-0500)] <wgthom> 'anyone' is a pretty broad concept
[13:26:30 CDT(-0500)] <serac> anyone in this context is any committer
[13:26:42 CDT(-0500)] <wgthom> when I was cutting releases for uP we routinely shared the between committers
[13:27:00 CDT(-0500)] <wgthom> so yes
[13:27:28 CDT(-0500)] <wgthom> whats in the release has already been decided.
[13:27:55 CDT(-0500)] <battags> and I'm on the hook for publishing it
[13:27:58 CDT(-0500)] <battags> and there was a site outage
[13:28:01 CDT(-0500)] <serac> I'll +1 this idea if we +1 formal release voting, otherwise I'm strongly opposed.
[13:28:30 CDT(-0500)] <serac> And the vote should end with the responsible release engineer.
[13:29:06 CDT(-0500)] <wgthom> not sure what that means
[13:29:22 CDT(-0500)] <wgthom> vote should end?
[13:29:23 CDT(-0500)] <serac> Not sure what to say to clarify.
[13:29:48 CDT(-0500)] <wgthom> how does a vote end with a RE?
[13:29:57 CDT(-0500)] <serac> When voting ends, if yea, then subsequently the release engineer should be named to do the work.
[13:30:23 CDT(-0500)] <wgthom> ah…yes…we should know who's on the hook for the build
[13:30:25 CDT(-0500)] <serac> I imagine it will be a collegial consensus.
[13:30:43 CDT(-0500)] <battags> can we vote for the release engineer? :-p
[13:30:51 CDT(-0500)] <wgthom> uhg...
[13:30:54 CDT(-0500)] <serac> haha
[13:30:56 CDT(-0500)] <battags> I vote for Andrew since he's not here
[13:31:03 CDT(-0500)] <battags> that's how we typically assign work
[13:31:03 CDT(-0500)] <battags> lol
[13:31:21 CDT(-0500)] <serac> I just want some extra checks if we're going to open this up.
[13:31:33 CDT(-0500)] <serac> Force some communication.
[13:31:46 CDT(-0500)] <wgthom> agreed
[13:32:18 CDT(-0500)] <serac> I'll send the proposal to cas-dev.
[13:32:20 CDT(-0500)] <battags> actually what I consider more important is assigning a publicist per release
[13:32:36 CDT(-0500)] <serac> How do you mean?
[13:32:43 CDT(-0500)] <battags> for example, I had the time to do the cas-client release and send out the dev email but no time yet to publish to all the other normal sources
[13:32:48 CDT(-0500)] <battags> Andrew nicely took that up to get it on the web site
[13:33:09 CDT(-0500)] <serac> Isn't all that covered, for the server anyway, on the release checklist?
[13:33:18 CDT(-0500)] <serac> I'm thinking when you volunteer, you volunteer for it all.
[13:33:26 CDT(-0500)] <serac> The good and the bad
[13:33:34 CDT(-0500)] <battags> its not a matter of good or bad
[13:33:40 CDT(-0500)] <serac> (it is for me
[13:33:53 CDT(-0500)] <serac> mvn deploy - good
[13:34:00 CDT(-0500)] <serac> writing news articles -bad
[13:34:03 CDT(-0500)] <battags> there are particular nuances in drafting a simple email announcement vs. blog posts, news articles, etc.
[13:34:19 CDT(-0500)] <battags> I don't consider that stuff to be really part of the release engineer job
[13:34:28 CDT(-0500)] <battags> right now we have it there
[13:34:49 CDT(-0500)] <wgthom> yea, it could be, but doesn't have to be
[13:34:58 CDT(-0500)] <serac> I don't think we have enough active devs/folks to make it work any other way.
[13:35:09 CDT(-0500)] <serac> I wish we had a secretary....
[13:35:12 CDT(-0500)] <battags> past experience has shown that I'm not really a bottleneck for doing the release itself
[13:35:18 CDT(-0500)] <battags> but I am for doing timely announcements
[13:35:20 CDT(-0500)] <battags>
[13:35:30 CDT(-0500)] <battags> because I start development right after on the next iteration
[13:35:37 CDT(-0500)] <serac> I would imagine we'd all be in that boat.
[13:35:55 CDT(-0500)] <battags> I don't know if someone can take up that responsibility
[13:35:55 CDT(-0500)] <serac> Coders code first and write dox last.
[13:36:06 CDT(-0500)] <serac> I'm happy to ask the question.
[13:36:11 CDT(-0500)] <serac> Doubtful we'll get takers.
[13:36:20 CDT(-0500)] <battags> I can craft the marketing stuff but it just makes me longer because I hate doing it
[13:36:31 CDT(-0500)] <serac> you and me both, bro
[13:36:46 CDT(-0500)] <serac> Andrew sure has a talent for that stuff.
[13:36:58 CDT(-0500)] <battags> I didn't want to say that because it might sound like I was volunteering him
[13:37:01 CDT(-0500)] <battags>
[13:37:01 CDT(-0500)] <serac> I'm ashamed to try to shackle him with it tho.
[13:37:07 CDT(-0500)] <serac> haha
[13:37:25 CDT(-0500)] <battags> plus I have an MBA so I really shouldn't hate it ha
[13:37:32 CDT(-0500)] <serac> haha – awesome
[13:38:51 CDT(-0500)] <wgthom> so we cut 3.4.9 tonight? this weekend? and then migrate to github? is that the plan?
[13:39:06 CDT(-0500)] <serac> Sure hope it's sooner than later.
[13:39:14 CDT(-0500)] <serac> Github anyway.
[13:39:40 CDT(-0500)] <serac> It just dawned on me in that infrastructure@ thread that cas doesn't have its own svn repo.
[13:39:43 CDT(-0500)] <serac> Nutty.
[13:39:53 CDT(-0500)] <battags> yeah all the projects share
[13:40:04 CDT(-0500)] <serac> No wonder revisions increment so frequently.
[13:40:21 CDT(-0500)] <battags> what? you don't think I'm just super active?
[13:40:22 CDT(-0500)] <battags> :-p
[13:40:30 CDT(-0500)] <wgthom> so 3.4.x maintenance continues on svn for bit…until rdy to switch to gitbug?
[13:40:33 CDT(-0500)] <serac> No disrespect, but it's pretty fast.
[13:40:42 CDT(-0500)] <battags> haha
[13:40:53 CDT(-0500)] <serac> We're going to have to set a cutoff date.
[13:40:57 CDT(-0500)] <battags> what is this gitbug you speak of?
[13:40:59 CDT(-0500)] <battags>
[13:41:00 CDT(-0500)] <serac> Then make the repo read-only for a time.
[13:41:12 CDT(-0500)] <battags> we need to do a trial run of the conversion
[13:41:31 CDT(-0500)] <battags> but as we trial we should be able to continue committing to SVN
[13:41:31 CDT(-0500)] <serac> I've already done it and I think it's good. Want to review?
[13:41:42 CDT(-0500)] <battags> yes but not right now
[13:41:48 CDT(-0500)] <serac> Sure, sure.
[13:42:04 CDT(-0500)] <serac> I'll import it to GitHub and share the link.
[13:42:12 CDT(-0500)] <wgthom> serac: is the up on public github?
[13:42:28 CDT(-0500)] <serac> Not presently, but I will do now.
[13:43:01 CDT(-0500)] <wgthom> scott: did you see my note about isExpired, throttling, and RegistryCleaner?
[13:43:50 CDT(-0500)] <battags> didn't get a chance to completely parse it yet
[13:44:11 CDT(-0500)] <battags> but in general a policy only has two states expired or not
[13:44:20 CDT(-0500)] <battags> so if you've got semi-expired or candidate for expired that's a problem
[13:44:32 CDT(-0500)] <wgthom> not true for the throttling policy that's there now
[13:44:55 CDT(-0500)] <battags> no it is
[13:44:58 CDT(-0500)] <battags> if you use it to fast
[13:45:00 CDT(-0500)] <battags> it expires itself
[13:45:05 CDT(-0500)] <battags> and you have to log in again
[13:45:39 CDT(-0500)] <wgthom> if you back off…you can use it again, no?
[13:45:54 CDT(-0500)] <battags> but then you didn't really hit the throttle point
[13:46:02 CDT(-0500)] <battags> its possible that its misnamed
[13:46:05 CDT(-0500)] <wgthom> i didn't see where there was a one switch
[13:46:07 CDT(-0500)] <battags> we have a lot of that
[13:46:26 CDT(-0500)] <battags> its throttling in the sense of if you use a ticket too fast you can't use the ticket any more
[13:46:33 CDT(-0500)] <wgthom> throttled tickets can be "expired" and then not expired
[13:46:33 CDT(-0500)] <battags> but its possible that it was named poorly
[13:47:25 CDT(-0500)] <battags> so I think where the ambiguity comes in is that we delete tickets we find to be expired immediately
[13:47:29 CDT(-0500)] <wgthom> in any case pretty sure there's a problem with the Cleaner and this approach
[13:47:54 CDT(-0500)] <battags> its also incompatible with CentralAuthenticationServiceImpl
[13:47:58 CDT(-0500)] <wgthom> cleaner just's asked isExpired...
[13:48:04 CDT(-0500)] <wgthom> not if it's been thottled
[13:48:50 CDT(-0500)] <wgthom> didn't follow re CASimpl
[13:49:58 CDT(-0500)] <battags> if you come to CASImpl and the ticket is expired we delete it
[13:50:57 CDT(-0500)] <wgthom> ah….ok. didn't see that
[13:51:21 CDT(-0500)] <battags> its an optimization to reduce the load on the cleaners
[13:51:41 CDT(-0500)] <battags> so you're screwed from multiple directions on unthrottling consistently
[13:52:02 CDT(-0500)] <battags> Bill, you really miss FishEye don't you?
[13:52:37 CDT(-0500)] <wgthom>
[13:53:07 CDT(-0500)] <battags> just an FYI I have an interview debrief to go to in 7 minutes
[13:53:12 CDT(-0500)] <battags> so I'll be cutting out a little before 3
[13:53:17 CDT(-0500)] <wgthom> ok
[13:53:46 CDT(-0500)] <wgthom> Ok…so we still have a problem with the Cleaner re throttling
[13:54:07 CDT(-0500)] <wgthom> ?
[13:54:24 CDT(-0500)] <wgthom> issues a ticket…cleaner runs just then…ticket throttled?
[13:55:45 CDT(-0500)] <wgthom> looks like all you need is ticket use and cleaner run collision to run into an issue
[13:56:49 CDT(-0500)] <battags> how big of an issue is this?
[13:56:59 CDT(-0500)] <battags> I mean you have to hit the throttle point AND do it at the same itme the cleaner runs
[13:57:02 CDT(-0500)] <battags> time*
[13:57:28 CDT(-0500)] <battags> its behavior is consistent with the CASImpl
[13:57:39 CDT(-0500)] <battags> (actually its better)
[13:57:47 CDT(-0500)] <wgthom> hows that?
[13:57:48 CDT(-0500)] <battags> if you need to actually throttle a user vs. kill their ticket
[13:58:03 CDT(-0500)] <battags> its better to not do that in the ticket itself
[13:58:08 CDT(-0500)] <wgthom> got a tgt….use is couple of times…run into the cleaner….
[13:58:24 CDT(-0500)] <battags> how short is your throttle period?
[13:58:54 CDT(-0500)] <battags> the existing throttle policy is really designed to catch robotic attacks, misconfigurations of clients, etc.
[13:59:04 CDT(-0500)] <wgthom> sure
[13:59:24 CDT(-0500)] <battags> we'll continue this later
[13:59:25 CDT(-0500)] <battags> gotta run
[13:59:30 CDT(-0500)] <wgthom> ok. later.
[13:59:31 CDT(-0500)] <battags> sorry!
[13:59:32 CDT(-0500)] <wgthom> have fun.
[14:01:12 CDT(-0500)] <serac> Still learning git, so be gentle.
[14:01:16 CDT(-0500)] <serac> https://github.com/serac/cas
[14:01:35 CDT(-0500)] <serac> What I'm primarily interested in is the preservation of history and proper branches.
[14:02:41 CDT(-0500)] <serac> master is pointed at 3.4.x main branch per CAS-997.
[14:03:15 CDT(-0500)] <serac> Looks like I lost other branches in the move to github.
[14:05:04 CDT(-0500)] <wgthom> cool
[14:06:13 CDT(-0500)] <wgthom> so this is essentially the HEAD of 3.4.x….soon to be 3.4.9?
[14:06:37 CDT(-0500)] <serac> That's my intention, and I believe it's that way.
[14:06:46 CDT(-0500)] <serac> HEAD as of the day I imported it.
[14:08:06 CDT(-0500)] <wgthom>
[14:10:28 CDT(-0500)] <wgthom> i get a little "Clone in Mac" button…think it will work?
[14:10:46 CDT(-0500)] <serac> No idea
[14:10:54 CDT(-0500)] <serac> Sounds easy to test
[14:11:47 CDT(-0500)] <wgthom> yep…just pulled down with mac github tool. cool.
[14:13:09 CDT(-0500)] <wgthom> nifty little commit history in the mac github tool
[15:29:08 CDT(-0500)] <apetro> didn't manage to wrap things up at the airport in time for the cas-dev timeslot today. Looks like I missed some discussion. Anyway, checking in. late.
[15:29:21 CDT(-0500)] <wgthom> howdy
[15:29:55 CDT(-0500)] <wgthom> https://issues.jasig.org/browse/CAS-1003?focusedCommentId=24057#comment-24057
[15:30:06 CDT(-0500)] <wgthom> summary of some of the discussion
[15:31:15 CDT(-0500)] <apetro> interesting
[15:31:33 CDT(-0500)] <apetro> I have to admit I'd never thought about that
[15:31:41 CDT(-0500)] <apetro> What's with this? throw new InvalidTicketException();
[15:31:56 CDT(-0500)] <apetro> that seems like it throws away too much information that could have helpfully been carried in the exception
[15:32:04 CDT(-0500)] <apetro> as in, why's the ticket invalid?
[15:32:12 CDT(-0500)] <wgthom> sure…good improvement
[15:32:22 CDT(-0500)] <apetro> k
[15:32:25 CDT(-0500)] <wgthom> invalid…cause it expired
[15:32:31 CDT(-0500)] <wgthom> invalid…cause it was throttled
[15:32:32 CDT(-0500)] <wgthom> ...
[15:32:41 CDT(-0500)] <apetro> invalid, cuz we ain't got no record of it
[15:32:42 CDT(-0500)] <apetro> etc.
[15:32:47 CDT(-0500)] <wgthom> yup
[15:32:58 CDT(-0500)] <apetro> yeah]
[15:33:46 CDT(-0500)] <apetro> you know, getting that exactly right would, if applied sufficiently in the past, save me personally hours lost to not "getting" what a 10 second ST expiration timer means in relation to my ability to manually step through the CAS protocol
[15:34:00 CDT(-0500)] <apetro> anyway. It's a nit.
[15:34:22 CDT(-0500)] <wgthom> lol
[15:34:50 CDT(-0500)] <apetro> I agree with moving the throttling abstraction up into the CASImpl, not conflating throttling with expiry
[15:34:58 CDT(-0500)] <wgthom> ITE only takes a throwable....
[15:35:14 CDT(-0500)] <apetro> I wonder if it's worth looking at other throttling and seeing if the throttling should be applied in teh same same place or way or analogously or what
[15:35:48 CDT(-0500)] <wgthom> like brute force password attacks?
[15:36:08 CDT(-0500)] <apetro> then ITE needs to take a message, maybe have more strongly typed subclasses if that's somehow valuable? A decent respect for YAGNI suggests taking a message would be sufficient.{color}
[15:36:17 CDT(-0500)] <apetro> exactly brute force password attacks
[15:36:19 CDT(-0500)] <wgthom> yep
[15:36:25 CDT(-0500)] <apetro> that's the only other throttling I'm aware of
[15:36:36 CDT(-0500)] <wgthom> restful interface?
[15:36:42 CDT(-0500)] <apetro> oh goodness
[15:37:26 CDT(-0500)] <apetro> all the more reason to apply throttling at CASImpl
[15:37:57 CDT(-0500)] <apetro> where it applies no matter what interface (REST? Web?)
[15:42:25 CDT(-0500)] <wgthom> like this better?
[15:42:26 CDT(-0500)] <wgthom> synchronized (ticketGrantingTicket) {
[15:42:26 CDT(-0500)] <wgthom> if (ticketGrantingTicket.isExpired()) {
[15:42:26 CDT(-0500)] <wgthom> ticketRegistry.deleteTicket(ticketGrantingTicketId);
[15:42:26 CDT(-0500)] <wgthom> throw new InvalidTicketException("Ticket is expired.");
[15:42:26 CDT(-0500)] <wgthom> } else {
[15:42:27 CDT(-0500)] <wgthom> // check for cool down
[15:42:27 CDT(-0500)] <wgthom> if (System.currentTimeMillis() - ticketGrantingTicket.getLastTimeUsed() <= minTimeBetweenUsesInMilliSeconds) ) {
[15:42:28 CDT(-0500)] <wgthom> ticketRegistry.deleteTicket(ticketGrantingTicketId);
[15:42:28 CDT(-0500)] <wgthom> throw new InvalidTicketException("Ticket used before cool down elapsed. Ticket has been throttled.");
[15:42:29 CDT(-0500)] <wgthom> }
[15:42:29 CDT(-0500)] <wgthom> }
[15:42:30 CDT(-0500)] <wgthom> }
[15:43:31 CDT(-0500)] <apetro> I do!
[15:43:56 CDT(-0500)] <apetro> I imagine those messages in the exception will help some poor adopter, or me, trying to troubleshoot why tickets aren't validating someday
[15:44:54 CDT(-0500)] <apetro> if we're down in the weeds, then I'll share that if I were doing this, I'd consider doing more heroics to extract some details and put them in those exception messages. How long was the cool down and how much before the cooldown was the ticket use attempt? When did the ticket expire?
[15:45:06 CDT(-0500)] <apetro> But that's probably a matter of style, and it hits diminishing returns fast
[15:45:12 CDT(-0500)] <apetro> still
[15:45:27 CDT(-0500)] <wgthom> yep....polish
[15:45:50 CDT(-0500)] <apetro> empathizing with the deployer: the kinds of things I tend to screw up are, say, units on timeouts, such that I'd set that timeout to 10... milliseconds, and bonus points for helping me to realize that here.
[15:46:00 CDT(-0500)] <apetro> agreed. Polish.
[15:46:22 CDT(-0500)] <apetro> conceptually, I like where you're going.
[15:46:51 CDT(-0500)] <apetro> along those lines, I really really like the word "milliseconds" being in that time between use variable
[15:47:08 CDT(-0500)] <apetro> units are the bane of my existence and it's harder than you'd think for me to figure out which units are in use where.
[15:48:15 CDT(-0500)] <wgthom> i guess it would be more consistent with core java api just to use Millis as in System.currentTimeMillis()
[15:48:26 CDT(-0500)] <wgthom> not as clear though