[ISS.0098.9014] BrokerException

, ,
1

Hi,

We are getting this error:[ISS.0098.9014] BrokerException: Broker Failure (100-2015): The operation failed because the Broker does not have enough storage to process the request. Alert your administrator for one of the flow execution.

Our servers are clustered and when executed in one server it works fine but in other its throwing the above error.

When we analysed further, we came to know that the flow uses send mail service where the mail notification is sent along with the attachment and from the logs we understand it fails in publish step. one of the service which sends the mail has this publish step and we think from there it fails for the above reason.

So could it be any property or settings issue at broker level for the mail service? Let us know your views on the same.

2

Hi Sharadiya,

can you depict the flow for sending the mails a bit more in detail please (especially for using publish)?

Please check the client queue length in the Messaging UI in MWS.
As well as the Utilization of the Broker storage files.

Regards,
Holger

3

Sharadiya – Which version of IS you are using, what fix levels. Also, did you define ports on both nodes of IS which are in cluster ?

Thanks,

4

Try increasing the BrokerData.qs.stor; Go to <webMethods_install_dir>/Broker/bin directory and use the command

server_config storage … (Refer Broker Admin guide for more details)

5

The fact that it works from one server in the cluster and not from the other is definitely puzzling. For now, let me just focus on the error message “Broker does not have enough storage.” Can you login to the server where the Broker is running and make sure there’s free disk space on the disk where the Broker keeps its storage files?

Percio

6

Hi All,

Thanks for all your suggestion!!!

This issue has now been resolved using a small code fix.

We were sending files via email in a loop, The file which was sent as an attachment to the email queue, grows in size for every iteration of the loop. As the loop runs as much as 600 odd times(in the current scenario), the trigger is slower to pick them up as the documents are big

In this case Even if we increase size of the storage, if the number of records in the file is going to increase even further, we may end up using all space.

So we have eliminated sending the emails in loop, instead we are sending a consolidate email now which has resolved the issue.

7

Hi Sharadiya,

sounds like a flaw in your original design if the attached file is increasing in each iteration.
This means, you have mailed the same data several times.
Instead you should have dropped and replaced the attached file with only the data of current iteration.

Glad to hear that you found a solution for your issue.

Regards,
Holger