-
Why are feedhandlers not usually kdb?
We often read that feedhandlers are not kdb, and usually are either java-kdb or C++, why is this the case? why is it not ideal or possible to have a kdb feedhandler?
-
2 Replies
-
Short answer, to my understanding, is that feed handler isn’t quite a good use case for KDB.
A feed handler needs to deal with data sources of various forms, and more generic languages like Java and C++ usually have richer support for those. Another thing to consider is parallel processing of those data feeds, which will be cumbersome if done in KDB given that in a usual setup, there is only one main thread processing incoming requests and the parallelism would call for a cluster of KDB processes.
-
Sometimes the only way to interact with the upstream data source is to use a library provided by the vendor. To use a library like that from q you need to write a plugin, and these plugins have a chance to crash unlike pure q code. Also you can’t just reimplement/reverse engineer the network protocol because as of 4.0 q still doesn’t have native raw TCP support. So even if the feed handler is a q app with a plugin, it is best kept as its own process to isolate the impact of a crash.
Log in to reply.