Make pstm handling thread sleep time configurable - #267
Conversation
| add_test(NAME pstm_deadlock_udpmc_test COMMAND pstm_deadlock_udpmc_test WORKING_DIRECTORY $<TARGET_PROPERTY:pstm_deadlock_udpmc_test,CONTAINER_LOC>) | ||
| setup_target_for_coverage(pstm_deadlock_udpmc_test SCAN_DIR ..) | ||
|
|
||
| #TCP Endpoint test is disabled because the test is not stable when running on Travis |
There was a problem hiding this comment.
Was this removed intentionally?
There was a problem hiding this comment.
Yes. If you look closely, it's trying to add a TCP test inside of the UDP block. The TCP block also adds this test, it must've somehow got duplicated.
|
|
||
| manager->loghelper = logHelper; | ||
| manager->verbose = celix_bundleContext_getPropertyAsBool(context, PUBSUB_TOPOLOGY_MANAGER_VERBOSE_KEY, PUBSUB_TOPOLOGY_MANAGER_DEFAULT_VERBOSE); | ||
| manager->handlingThreadSleepTime = celix_bundleContext_getPropertyAsLong(context, PUBSUB_TOPOLOGY_MANAGER_HANDLING_THREAD_SLEEPTIME_SECONDS_KEY, PSTM_PSA_HANDLING_DEFAULT_SLEEPTIME_IN_SECONDS); |
There was a problem hiding this comment.
Just wondering, doing this in the create makes it impossible to update the timeout when the component is active.
Getting it where needed, makes this possible. (I doubt this use case is needed..)
Any specific reasons to do it here and not in the handler thread?
There was a problem hiding this comment.
No specific reason, no. Just another case of ctrl+C, ctrl+V.
There was a problem hiding this comment.
I don't think the overhead of calling celix_bundleContext_getPropertyAsLong() matters much, but that's the only reason I can think of not wanting to do it inside of the loop.
There was a problem hiding this comment.
Maybe thread-safety? Hrm.
There was a problem hiding this comment.
I'm fine with this solution, if it ever comes up again, we can always take a look at potential risks. I doubt anyone is going to change the timeout at runtime.
3 participants
No description provided.