KX Community

Find answers, ask questions, and connect with our KX Community around the world.

Home Forums kdb+ Why are feedhandlers not usually kdb?

  • Why are feedhandlers not usually kdb?

    Posted by mannix on January 29, 2023 at 12:00 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?

    mannix replied 2 months, 1 week ago 3 Members · 2 Replies
  • 2 Replies
  • darrenwsun

    January 30, 2023 at 12:00 am

    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

    January 30, 2023 at 12:00 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.

Log in to reply.