Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 16:39
    ejsmith synchronize #452
  • 16:39

    ejsmith on elastic7

    Log the correct task id and cat… (compare)

  • 06:25
    ejsmith synchronize #452
  • 06:25

    ejsmith on elastic7

    Minor (compare)

  • 06:00
    ejsmith synchronize #452
  • 06:00

    ejsmith on elastic7

    Add missing task id (compare)

  • Dec 13 22:43
    ejsmith synchronize #452
  • Dec 13 22:43

    ejsmith on elastic7

    More reindex job changes (compare)

  • Dec 13 15:46
    ejsmith synchronize #452
  • Dec 13 15:46

    ejsmith on elastic7

    Just retry 3 times (compare)

  • Dec 13 15:44
    ejsmith synchronize #452
  • Dec 13 15:44

    ejsmith on elastic7

    More log message changes (compare)

  • Dec 13 14:25
    niemyjski synchronize #452
  • Dec 13 14:25

    niemyjski on elastic7

    Added retry reindex for disconn… (compare)

  • Dec 13 14:09
    niemyjski synchronize #452
  • Dec 13 14:09

    niemyjski on elastic7

    Updated migration to retry sock… (compare)

  • Dec 13 04:51
  • Dec 13 03:28
    ejsmith synchronize #452
  • Dec 13 03:28

    ejsmith on elastic7

    Oops progress (compare)

  • Dec 13 03:04
    ejsmith synchronize #452
Blake Niemyjski
@niemyjski
    public override Task<ILock> GetWorkItemLockAsync(object workItem, CancellationToken cancellationToken = new CancellationToken()) {
        var cacheKey = $"{nameof(RemoveOrganizationWorkItemHandler)}:{((RemoveOrganizationWorkItem)workItem).OrganizationId}";
        return _lockProvider.AcquireAsync(cacheKey, TimeSpan.FromMinutes(15), new CancellationToken(true));
    }
Eric J. Smith
@ejsmith
I’m not sure how the 1 time work item handler would be different than just adding the getworkitemlock
guess it could just be a shortcut that just calls GetKey for you in the GetWorkItemLock
Blake Niemyjski
@niemyjski
yeah
could make these a lot more easier to use if we put a generic on workitemhandler<WorkItemHandlerBase>
but that might make other things harder todo..
Eric J. Smith
@ejsmith
how long would we hold the lock for?
huh?
Blake Niemyjski
@niemyjski
15 minutes or until we release it or renew it
Eric J. Smith
@ejsmith
that isn’t really 1 time.
I think the idea should be that 1 time means 1 time… meaning we set a key that doesn’t expire for like 24 hours or something.
so just do a throttling lock provider for 1 hit every 24 hours
should keep it from happening again.
kind of feel like we should make people implement that themselves.
because 1 time sounds like its gauranteeing more than just thottling it for 24 hours.
and it’s really not saving much.
Blake Niemyjski
@niemyjski
changes pushed
heading to gym
to me
one time means the job is ran one time
once it’s ran it can run again
Eric J. Smith
@ejsmith
right
and putting a lock for 24 hours
Blake Niemyjski
@niemyjski
like throttleing events on an ip is a one time job that might happen repeatidly
Eric J. Smith
@ejsmith
doesn’t guarantee shit
and they aren’t saving much work over doing the lock themselves.
Blake Niemyjski
@niemyjski
guess there is confusion on what one time job means
Eric J. Smith
@ejsmith
so I say we let them do the lock themseleves.
Blake Niemyjski
@niemyjski
yeah
lets remove it
Eric J. Smith
@ejsmith
ok
do it
Blake Niemyjski
@niemyjski
I agree
simple enough for me to just do this
Eric J. Smith
@ejsmith
yeah
we might add another lock provider that persists the fact that something has run permanantly.
could be useful for running migrations
that should happen 1 time EVER
Blake Niemyjski
@niemyjski
pushed
Eric J. Smith
@ejsmith
ok
Blake Niemyjski
@niemyjski
yeah
:)
ok pr is updated
heading to the gym for an hour
then dinner and I’ll be on
Eric J. Smith
@ejsmith
no tennis, so I might work some tonight.
worked all damn weekend though.
so it’s a maybe.
Blake Niemyjski
@niemyjski
at least review my two pull requests
lets met up for 20 minutes so I can go over the stats stuff