There is always a lot to do when you run your page. And, somehow, these days there are some default limits to the amount of work you are supposed to do.
Okay, but what does this mean…
In an application, we have a screen to create some appointment between a bunch of people. This bunch can become quite substantial indeed.
In those days we were running Oracle HTTP Server 9i to lift mod_plsql up in the IP, and we never had any issue creating these somewhat larger appointments in our application.
Recently we got a call on our service desk, which said there were some issues in creating an appointment with a greater number of participants. The message read, somewhere in the error-text:
“HTTP-400 Too many arguments passed in. Got 2009 parameters. Upper limit is 2000”
Okay, somehow this application function is not going to work!
On research we identified the parameter PlsqlMaxParameters to be the problem. This parameter was introduced with the first version of Oracle HTTP Server right after 9i. If unset, PlsqlMaxParameters defaults to a value of 2000.
I am guessing here, but my bet would be this to be a restriction to prevent a buffer-overrun of some kind.
To resolve the issue the PlsqlMaxParameter needed to be added to plsql.conf. (We tried to do this in dads.conf to keep most of Oracle HTTP Server unaffected, but got errored out).
We chose the value of 4000, meaning a 100% increase while maintaining a fair and safe limit.
For Oracle HTTP Server, the parameter is set in plsql.conf which can be found in either:
For Oracle EPG, the parameter can be set as follows:
- dbms_epg.set_global_attribute(‘max-parameters’, ‘100’);
And this is where it gets tricky!
Currently we are leveraging Oracle 11g Standalone HTTP Server (22.214.171.124), so without this bulky and difficult WebLogic overhead and we thought we’d aught to test this installation with these big appointments.
As expected, we received an error-message, so the behavior is consistent for this part. The scary bit though was that the error-message is no longer an error-message but a hint to go in the woods…
“The request could not be understood by the server due to malformed syntax.”
Which could virtually mean anything, and if we hadn’t run into the previous error, we’d have a helluvatime trying to resolve this.
Luckily the theater was set and we knew what we were searching for and testing, so we quickly resolved this also by adding PlsqlMaxParameters.
I hope this post will help you troubleshooting this catch-all message too!
Update on July 25th 2014
As we’re running into problems a new, I decided to call upon Oracle Support too… Raise and SR and see what comes floating to the top.
Well, a confirmation of what we already concluded, there is no conclusion…
I'm not able to determine what the maximum value is that you can set this to as it does not appear to have been documented in the bug, and the parameter has not been documented at all in the product documentation. I don't have access to the source code, so I'm not able to see if a hard limit has been set or not.
Raising the number of MaxPlsqlParameters is not considered to be a definite solution. Which kinda sounds logical since where you need a page-call with more than four thousand !! parameters (or even 2,000 when you think of it), you would think something could be optimized.
And the suggestions of MOS, which I will support:
- I would suggest you raise the value to what you need it to be for your environment. If there is a hard limit in the code, and you configure this above that limit, then you will get an error.
- I would then suggest you look into your application and work to reduce the number of parameters as per the recommendation of the developer of the parameter.
One thought on “Communication limit with mod_plsql through PlsqlMaxParameters”
very interesting and very inspiring article for me