Why are feedhandlers not usually kdb?

[Mannix]

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?

[darrenwsun]

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.

[gyorokpeter-kx]

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.