Look at the following code:

MODIFY FILE CNTEMP
FIXFORM FROM HOLD
MATCH RM_CLID RM_SEQ
    ON MATCH COMPUTE EXCLUDE_FLAG=6; PLCIND='I'
    ON MATCH UPDATE EXCLUDE_FLAG PLCIND PL_BEGDT
    ON MATCH/NOMATCH GOTO TOP
DATA ON HOLD
END

The code is missing a semi-colon after the PLCIND='I' and this missing semi-colon caused the Reporting Server to freeze up after it used all available memory and all available swap space. I've been using FOCUS and WebFOCUS for almost 30 years and a missing semi-colon has ALWAYS thrown a syntax error.

Just curious if anyone else has had this happen or am I just lucky?

This is on WebFOCUS 8.08

I did open a problem report with IBI

This message has been edited. Last edited by: <Kathryn Henning>,

JGELONA,

have you thought about adjusting your agents to stop after x amount of time has passed, or x amount of resources have been used? This would prevent your RS from allowing 1 agent to take up all of its processing power and crashing your server.

eric, that wouldn't work here, maybe limiting resources would but processing time wouldn't. We have reports that run in under a second and batch processes that run in 30 minutes or longer. In this case, from when the job starts to when the reporting server becomes unresponsive is about 20 seconds. Here's what IBI says after some initial testing:

"I put together a test that closely resembles what you provided. So far I can see that the agent itself is unresponsive. When monitoring the agent I see that it is not using any CPU, but memory is steadily increasing.

I tested in several releases and see the same behavior in-house. I will research and get back to you."

While not the same behavior as here, a syntax error is not generated, which is the problem.

Update from IBI:

"I believe I've reproduced the same behavior and have sent the issue over to engineering. They are working on it now. I will keep you posted of their findings."

If your RS is reaching its maximum memory limit that quickly, I would probably put a limit to how much any one agent can take. When you start to have users trying to process large amounts of data on the RS, you will probably run into a similar issue as you are seeing with this bug. CPU or Time might not help in this instance, but it sounds like you have a rather finite amount of memory, protecting against people eating all of that is probably something you want to do anyways (Just my 2 cents)

As for processes that might be outside of that, you can always create a secondary Data Service to handle those requests that you feel needs to handle more memory, or have less restrictions. Maybe something like an "Adhoc_Users' Data service and a "Dev_Users' Data Service. This way you can put anyone writing untested, non-production queries into a safer zone and allow people who know what they are doing to have a little more freedom. In one of my previous "lives" we had our system set up that any user could run no more then 3 foreground reports at a time. But when we would build our dashboards we would need to fire off 5 -7 or more requests. To avoid this we created a Dashboard Data Service that didn't restrict the amount of agents a user could have on that service. We made sure to only attach this Data Service to reports that we had built to be fast and that worked off of Aggregated Tables. These requests would generally take no more then 10 -15 seconds (which for that place was blazing fast as most queries toke 3 - 10 minutes). Just something to consider for the long term health of your system. Its obviously not a fix as it seems that IBI is helping you work through the actual problem, but it might be necessary to prevent your users from being able to crash your system.

Hi jgelona,

It looks like a case has been opened to handle this issue. Please share with us what the final resolution is so that others can benefit as well.

Thanks and regards,

Kathryn