Cloverleaf xlate message size limitations?

I would be curious to know if you take the xlate out of the equation and do a raw route on message type does the panic still occur.

In my opinion for a real-tme message I get concerned whenever exceeding 64K, mostly because I’ve seen this limitation on a number of vendor interfaces, so 10MB might be a challenging size.

I’m curious to hear if others have experience moving messages of this size because I don’t since I’ve warned against doing it and found alternative methods.

I’ve resorted to alternative methods such as passing pointers to the data in the real-time messages when dealing with large data blocks like a huge document or a scanned image.

Also, from past eperience when dealing with potentially unlimited repitions there will always be someone who runs a muck and there should be checks in place to make sure an excessively large message can’t flow across the interface as is, else you will get something too large to handle eventually.

The max message size will be limited to the capability of the weakest link in the integration chain which will be one of these:

– source system

– cloverleaf

– down stream system(s)

Greetings,

Other thoughts here:  perhaps the maxuprocs settings need to be upped

to allocate more memory to the engine processes.  You did not state what version of the integrator you are running or on what platform; but in our case, we followed the Cloverleaf support recommendations to up these parameters for our engine user accounts = hci and hcitest.  

Being on AIX we run the following to see what the current values are:

> ulimit -a

By upping the data, stack, and memory values by a factor of 3 we have been able to process large messages via an xlate without issues.

I know I failed to define “large” but we get some really big files with embedded pdf format codes, etc. from applications like OnBase.

Also: you may wish to consider isolating your xlate to a dedicated process

that is, the one inbound – xlate – outbound as its own process to isolate it from any other demands on the xlate cmd thread.

Again, just some thoughts to ponder in figuring out how to get around this problem.

And then again, if there is NOT that much the xlate needs to do then consider a TCL solution.

Hope this helps you out.