Is there a relation between the memory usage and the number of packages existing in the server?
Trying to understand if it is an advantage to use less packages in terms of memory usage. Currently our architecture has been based on this constrain, but until now I have not found any reference in the documentation whatsoever that refers this limitation.
I think it is a better architecture to split the source in small (in functional terms) packages, it makes the source more reusable and portable.
There is no limit to the number of packages.
if you have more packages or services then startup time will be more.
as active packages will be loaded to memory, make sure you have enough memory allocated to IS.
Hi Luis,
When Integration Server is started, packages gets loaded into memory (i.e. the elements residing in the package occupy a significant amount of memory but not the package).
Packages are designed for Re-usability. It is always good to design an interface maintaining 2-3 packages (Processing services package, resource package, etc.)
Advantages of packages split based on functionality:
When FunctionA package is deployed/reloaded due to a configuration change, other Functions packages are not impacted.
Deployer takes package as a unit and deploy to respective target servers. So when package size is more (say 4MB), you might see that deployment takes more time than expected or timeout occurs.
It is just that maintaining is difficult if you split to more number of packages (let us say you created 10 packages for one interface).
Startup Time of IS increases with the number of packages and the number of nodes inside the packages.
So the minimum Java Heap Size should be big enough to hold at least all nodes during initialization to avoid increasing jvm memory during startup.
It turned to be a best practice to separate the generated services for Business Process Model Steps from their implemented logic on 2 different packages.
By doing so the generated services can be deleted and regenerated without loosing implementation.
Additionally this eases the deployment of process models as these are usually quite stable where as the implementation can encounter changes in the logic which does not affect the model itself.
It is not always neccessary to deploy the whole package when there only a few services have been changed inside the package. Deployer is able to deploy partial packages containing only the changed services.
Having 10 packages with 10 nodes (not only services are recognized as nodes) should require the same amount of memory as 1 package with 100 nodes or 100 packages with each 1 node for example.
All of these scenarios are still 100 nodes.
Additionally the complexity of the services is a factor here.
Having large, complex flow services requires more memory than i.e. some small trigger nodes.
Additional information:
When having more packages, the loading time is also affected by the complexity of the inter-dependency of the packages.
In the first run, all the packages are scanned for their manifest.v3 files containing the dependency information.
When packages depend on each other they have to be loaded in the right order in the same ClassLoader Thread whereas packages being completely undepended on others (except i.e. WmPublic et al.) are each loaded in separate ClassLoader threads.
At least for me it turned out to have the following grouping/splitting of nodes is a good practice:
One package for each IS containing environment specific data as AdapterConnections and AdapterListeners
Some packages (dependent on purpose) which are the same for all ISes containing general Utilities and HouseKeeping functions.
Per project/Interface:
– One Package with specific AdapterService, AdapterNotifications, DocTypes, Logic, ModelLogic Implementation, Triggers, WSDs
– One Package with the generated part for the process models invoking the appropriate ModelLogic Implementation service in the above package.
Hi Holger, many thanks for your feedback and also to the other forum members.
My question started exactly with this feature that I think each package requires it’s own classloader and therefore the more classloader the higher the resource comsuption.
For the startup load I already noticed that yes the more packages the more time efectivly it takes, and it makes sense as you have explained with the manifest check.
From package management I believe that at least there should be two levels one for the system that we are connecting to, so that it gets encapsulated in a single module and another at the service exposure level where each service or a group of related services are contained. I think this leverages the reusability and hence the decoupling principle that is one of the pillars of SOA.