2023.01.29 10:54 AM
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?
2023.01.29 05:12 PM
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.
2023.01.30 02:28 AM
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.
Tel: +44 (0)28 3025 2242
Tel: +1 (212) 447 6700
Tel: +61 (0)2 9236 5700
KX. All Rights Reserved.
KX and kdb+ are registered trademarks of KX Systems, Inc., a subsidiary of FD Technologies plc.