Requests bound to ThreadLocal

[thiagonuic]

Hi,

Do you know if each request is safe to assume to keep on the same Thread throughout the life of it? In Kotlin basically would mean no coroutines I guess. I want to bind some things to ThreadLocal, but in order to do so in a safe way, each request needs to stay on the same thread the whole time.

Cheers,

[davidepianca98]

Do you know if each request is safe to assume to keep on the same Thread throughout the life of it? In Kotlin basically would mean no coroutines I guess. I want to bind some things to ThreadLocal, but in order to do so in a safe way, each request needs to stay on the same thread the whole time.

At the moment KMQTT is single threaded and kotlin coroutines are not used. I haven't tried it myself but it should be fine to do what you're asking.

[davidepianca98]

Now I understand your problem. Yes indeed the HTTP request would have to finish and the method to return before the broker can continue handling the other packets. That's bad but it's a possibility I didn't think of and the thread pool would solve that to a certain degree, at least until all the threads are used and waiting for the HTTP response, a thing that hopefully wouldn't happen.
Unfortunately I can't start working on this for the next two weeks at least.

[thiagonuic]

If you could point me to the right direction I can try to have a look at a possible way to do it. I know some projects are reviewing the idea of having thread pools and using more reactive approaches. But in this case the hanging of the main thread could be a problem unless the processing of the packet is super quick.

[davidepianca98]

It's definitely more of a problem doing blocking things in callbacks but it's a possible use case and I would like to support it. With the tests I've done the packet handling itself is plenty fast as is.
I think you could start having a look here if you want to help https://github.com/davidepianca98/KMQTT/blob/master/src/jvmMain/kotlin/socket/ServerSocket.kt . The problem is that probably many things will need to be changed to allow multi threaded support as most of the state of the broker will need to be synchronised. I also would like to use coroutines and flows/channels to simplify the handling and to have most of the synchronization in the common files and not only for the JVM as the point of the project is to be able to use the library on any platform.
I will start having a look at this myself anyway in a few weeks. In the meantime you could try anyway doing the HTTP requests, but if you need one per packet it's definitely not feasible now if you have many clients.

[thiagonuic]

We starting the project in a couple of weeks and the number of clients should not be too crazy, so I think the single thread should handle for the starting of it. But for the long run, it is definitely something to be aware of.

I will try to have a look at the things to be changed and I will let you know if I manage to progress on it.

The use of coroutines could be problematic because even though it sounds nice, it is not as flexible as the Go ones. The reason is because of the Kotlin coroutines are still bound to the IO blocking of the JVM. At first when I was studying about I thought it was a better solution, but when I saw the blocking IO problem, it means that the HTTP would still block the thread.

[davidepianca98]

If I'm not mistaken the Ktor client library has an engine that handles HTTP requests asynchronously in coroutines, so that would solve the issue.