Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#489 closed enhancement (fixed)

Config timeouts: receiving response, stop trying, stop for specific client

Reported by: shane Owned by: jelte
Priority: medium Milestone: R-Team-Sprint-20110208
Component: resolver Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity:
Sub-Project: Feature Depending on Ticket:
Estimated Difficulty: 2.0 Add Hours to Ticket: 0
Total Hours: 3.0 Internal?: no


Config timeouts: receiving response, stop trying, stop for specific client

  • need timer to stop trying

Should be copy & paste from existing code.


Change History (10)

comment:1 Changed 50 years ago by jelte

  • Add Hours to Ticket changed from 0.0 to 3.0
  • Total Hours changed from 0.0 to 3.0

comment:1 Changed 9 years ago by jelte

  • Owner set to jelte
  • Status changed from new to assigned

comment:2 Changed 9 years ago by jelte

  • Owner changed from jelte to UnAssigned
  • Status changed from assigned to reviewing

branched from master, so this only works on forwarder right now, and lookup timeout has the same effect as client timeout

removed the original timeout value, and replaced it with three timeouts:
query_timeout (timeouts for queries we send to servers)
client_timeout (timeout to send an answer back)
lookup_timeout (timeout to stop trying)

configuration additions in b3ec8dc3523bf2573cdc33a73eb21605d8a32305

actual use additions in 8f23ba4a72eed354852b023a4d41adfe4a62bb0c

(see commit log messages for some more notes)

comment:3 Changed 9 years ago by smann

  • Owner changed from UnAssigned to smann

comment:4 Changed 9 years ago by smann

  • Milestone changed from R-Team-Sprint-20110208 to R-Team-Sprint-20110125
  • Owner changed from smann to jelte

Changed a couple instances of EXPECT_EQ with EXPECT_FALSE. Built, ran, tested fine. As noted in the code, we certainly need more thorough tests.

Also, default settings of timers needs to be standardized (and not as given in src/lib/asiolink/asiolink.h), but ok for now. Further, exposing these timers to the user suggests that we should use gettors to retrieve their values (since configuration could change these values at any time) as opposed to passing them as arguments into the object. Thoughts?

comment:5 Changed 9 years ago by jelte

  • Owner changed from jelte to smann

One thing that comes to mind is that we also need to disable turning them off completely (currently done by making them -1), as that is only footshooting material that does not provide any value imo.

For default settings, do you mean use the defaults from the .spec? (i'm about to create a ticket for that, as that is something different that this imo).

As for the gettors, right now this isn't a real problem, since the whole object is recreated right now (which we will also need to address at some point). But yes. I'm thinking of adding a ResolverOptions? object for these things, to be directly replaced and used (containing only getters and setters). If we all agree, I think that should be a separate task as well :)

comment:6 Changed 9 years ago by stephen

  • Milestone changed from R-Team-Sprint-20110125 to R-Team-Sprint-20110208

comment:7 Changed 9 years ago by smann

  • Owner changed from smann to jelte

With respect to disabling, when/if you create the ResolverOptions? object, it could have an enabled flag associated with each option (or, perhaps, group of options). This adds more overhead, but may add clarity. Although, you could still shoot yourself in the foot.

Yes, defaults from spec (sorry, still getting used to that implementation).

+1 on gettors/settors. Separate task. Will you open a ticket for that as well?

Otherwise, I think that this task is done and ready to be merged.

comment:8 Changed 9 years ago by jelte

  • Resolution set to fixed
  • Status changed from reviewing to closed

well, given the current way runningquery works, these are created and live until they are either done or fail, having no timeouts at all is a memory leak (and a dos if timeout is set too high). One currently half-baked idea is having a fixed set of available runningquery objects to use (and probably drop the oldest one if we run out), which would be more efficient and solve that specific problem.

for the defaults there is a ticket already (#518), will create the other task later (perhaps warrants a bit of discussion on what it would look like and where the task would fit)

Merged, closing ticket.

comment:9 Changed 9 years ago by jelte

  • Add Hours to Ticket changed from 0 to 3

forgot to set hours, making it 3 as it turned out to be slightly more complicated due to finding the right way to delete objects.

Note: See TracTickets for help on using tickets.