Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

High memory consumption of HAPI messages #96

Open
winne42 opened this issue Jul 13, 2023 · 0 comments
Open

High memory consumption of HAPI messages #96

winne42 opened this issue Jul 13, 2023 · 0 comments

Comments

@winne42
Copy link

winne42 commented Jul 13, 2023

Hello, I am looking for advise on how to handle a large amount of HAPI HL7 messages in memory.

In our use-case, we want to store many ORU_R01 messages in a queue and send them from the queue to an HL7 target. The messages contain e.g. 200 OBX segments and the string representation of each message is around 30..50 KB in size. Unfortunately, the HAPI representation in memory is around 3 MB each! We have confirmed this with different profiling tools. Therefore we are not able to follow our original idea and store more than 10,000 messages in a "sending queue".

We will now store the messages' string representation in the queue instead. Unfortunately, the Initiator interface does not offer a message to sendAndReceive() strings. So now we need to take the memory-saving string representation of the ORU_R01 message, parse it into an ORU_R01 object again and then call sendAndReceive() which in turn serializes the ORU_R01 object to a string again... This obviously wastes CPU cycles, which can become significant in case of a large number of messages.

Is there any other way to handle this problem, anything we have missed? How do other HAPI users handle larger numbers of messages in memory? We could offer to make a PR adding sendAndReceive(String) to Initiator, but is there a realistic chance that HAPI HL7v2 will get a new release soon?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant