KX Community

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

Home Forums kdb+ Concurrent user request issues for sequential processing of processes

  • Concurrent user request issues for sequential processing of processes

    Posted by k-mambo on April 10, 2022 at 12:00 am

    Although we know it as the best solution in the financial or IoT field, we have identified an issue where the process is basically sequential and a single process can handle only one request at the same time.

    If you have checked the documentation for load balancing or query routing, but each of the distributed processes is waiting for a response, it is the same that many requests cannot be processed simultaneously.

    I want to know how many processes are designed to work in a case that actually operates reliably. In general, please include the minimum specifications of the server according to the amount of data.

    k-mambo replied 8 months, 1 week ago 2 Members · 3 Replies
  • 3 Replies
  • davidcrossey

    Member
    April 11, 2022 at 12:00 am

    To handle multiple concurrent client sync requests you could consider using deferred response to suspend sync queries whilst they are being processed, allowing your gateway to process further client requests. The result will be returned to the client when processing has completed.

  • k-mambo

    Member
    April 13, 2022 at 12:00 am

    I’m sorry for the late reply because I was testing.

    A gateway process was run to attempt a deferred response, but the Java client request is synchronized, so the request is processed sequentially by the gateway.

    Do you have any more information to refer to?

  • davidcrossey

    Member
    April 14, 2022 at 12:00 am

    Check out the architecture diagram on Sync requests – KX Platform for an idea of how you could set this up.

    Your Java client can use sync requests with a Gateway (GW) process.

    The GW can then defer the response to the Java client and send the query (async) through a Query Router (QR), thus allowing the GW to handle more client requests.

    Queries then flow on to a Query Process (QP) which completes the actual work, before sending the result back to the GW, and then finally the client.

    Please also see information on Callbacks

Log in to reply.