Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2018-11-20T21:06:12Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/260Follow-up from "WIP: Resolve "Congestion handling - add receive thread and pa...2018-11-20T21:06:12ZMarcin SiodelskiFollow-up from "WIP: Resolve "Congestion handling - add receive thread and packet queue"The following discussions from !103 should be addressed:
- [ ] @marcin started a [discussion](https://gitlab.isc.org/isc-projects/kea/merge_requests/103#note_28121): (+4 comments)
> I have some worries about this initialization pa...The following discussions from !103 should be addressed:
- [ ] @marcin started a [discussion](https://gitlab.isc.org/isc-projects/kea/merge_requests/103#note_28121): (+4 comments)
> I have some worries about this initialization part being done in the thread and not really guarded from concurrent access to IfaceMgr. Although unlikely, there is a possibility that ifaces_ is modified while the thread is starting up. To mitigate this problem, the method which starts the thread should maybe wait for it to signal that it has been initialized and the for() loop has started. I mean, we should maybe revise the whole IfaceMgr to see whether something in it can be modified that is concurrently used in the thread and not allow such modification if the thread is running? Specifically, sockets and interfaces should not be touched while the thread is running because even the for() loop accesses them.
- [ ] @marcin started a [discussion](https://gitlab.isc.org/isc-projects/kea/merge_requests/103#note_28138): (+3 comments)
> Parameters of the constructor aren't properly documented.
- [ ] @marcin started a [discussion](https://gitlab.isc.org/isc-projects/kea/merge_requests/103#note_28180): (+4 comments)
> That deserves some comment.
- [ ] @marcin started a [discussion](https://gitlab.isc.org/isc-projects/kea/merge_requests/103#note_28205): (+5 comments)
> I was scratching my head how is the new IfaceMgr code compatible with perfdhcp, which is also using receive4() and receive6() functions, but it doesn't (at least not explicitly) start receiver thread? On that matter, I also wonder if it shouldn't be optional to use the thread? perfdhcp probably doesn't want to drop any packets in the ring buffer?Kea1.5-beta2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/57Fixes as a result of profiling the HTTP code and control channel2018-11-15T12:24:25ZGhost UserFixes as a result of profiling the HTTP code and control channelThere are the following issues pertaining to JSONFeed and Http parsers which per my profiling tests seems to be first candidates for fixing:
* JSONFeed::postBuffer expensive because of making new allocations all the time
* JSONFeed::pop...There are the following issues pertaining to JSONFeed and Http parsers which per my profiling tests seems to be first candidates for fixing:
* JSONFeed::postBuffer expensive because of making new allocations all the time
* JSONFeed::popNextFromBuffer makes many buffer de-allocations
* JSONFeed::innerJSONHandler should not transition if the state remains the same
* HttpResponseParser body handler is inefficient as it reads characters one by one
* Connection::doTransaction should not reinitialize the parser all the time as it triggers expensive reinitialization of the state machineKea1.5-beta2