[Public] Understanding IronPdfEngine and its implementation in IronPDF Java and NodeJS
Implementation and Limitation
Default behavior of IronPDF Java and IronPDF NodeJS
Connecting IronPDF Java and NodeJS applications to a single IronPdfEngine instance.
Running 2 instances of application that uses IronPDF NodeJS and IronPDF Java on the same engine port is not allowed
Horizontal scaling of IronPdfEngine is not allowed due to loaded PDF data in memory cannot be shared between engine instances. Vertical scaling needs to be used instead by scaling up the instance resources
.png?width=670&height=980&name=Diagram-4-1%20(3).png)
Users can also scale the application instance horizontally instead of scaling the engine. Users can dockerize their app and once horizontally scaled, the each instance of the app will run in the default behaviour, in an isolated environment.
Summary:
- IronPDF Java and IronPDF NodeJS default behavior is that they will spawn a subprocess that talks with IronPDF Engine via gRPC that runs in port 33350
- This causes limitation where running multiple instance of the app on the same machine is not allowed. Set different engine port is needed for each app instance if this is required.
- Instead of using the default behaviour, users can also pull IronPdfEngine from Docker, and connect it to multiple application instance that runs with IronPDF NodeJS and IronPDF Java
- It is not allowed to horizontally scaling IronPdfEngine Docker, however vertical scaling can be done. Users can also horizontally scale their application instead and let the app runs with its default behaviour in isolated container to further optimize request traffic