Twice in the last 2 months, I have been notified by my customers that when they run an MR report from our BID, they receive a 'No agents available' error message.

From an administrative perspective, there are no active agents on the Server Console (Monitor > Data Services (Agents)) and nothing is running in ReportCaster. Matter of fact, to the best of my recollection, they've both occurred during relative lulls (one was on a Friday afternoon before a holiday weekend at 3:00 - a virtual ghost town).

What could be causing this, or more importantly, how do I resolve this?

- ABT

This message has been edited. Last edited by: ABT,

Do the reports in question have a -SET &ECHO=ALL; in them?
We have had issues with that error if this setting is left in. Our practice is to move it out after testing is finished.

How is the WebFOCUS server set up ?

For DEFAULT, WC_DEFAULT and DFM_DEFAULT, what are the settings ?

Maximum, Number_ready, agent_refresh, etc.

How are the users connecting, is it "online", i.e. will go to the default service.

quote:

Originally posted by Waz:
How is the WebFOCUS server set up ?

For DEFAULT, WC_DEFAULT and DFM_DEFAULT, what are the settings ?

Maximum, Number_ready, agent_refresh, etc.

How are the users connecting, is it "online", i.e. will go to the default service.

The users normally connect through the Business Intelligence Dashboard and run the FOCEXEC via a link via the domain listing. This runs as DEFAULT. Developers run via Dev Studio which also reports in the DEFAULT Data Service.

As requested:

service  		DEFAULT 
maximum  		50
number_ready  		2
deployment *  		private
Queuing *  		off  
idle_session_limit  	-1
idle_agent_limit  	120
profile *  		
cpu_limit  		-1
memory_limit  		-1
connection_limit  	-1
max_connections_per_user *  	-1
agent_refresh  		100
sched_priority  	0 (normal priority)


service  		WC_DEFAULT 
maximum  		2
number_ready  		2
deployment 		private
Queuing *  		on
maximum_q *  		20
queue_limit  		-1
idle_session_limit  	-1
idle_agent_limit  	-1
profile *  		
cpu_limit  		-1
memory_limit  		-1
connection_limit	-1  	
max_connections_per_user	-1
agent_refresh  		100
sched_priority  	0 (normal priority)

service  		DFM_DEFAULT 
maximum  		10
number_ready  		0
deployment *  		private
Queuing *  		off  
idle_session_limit  	-1
idle_agent_limit  	120
profile *  		
cpu_limit  		-1
memory_limit  		-1
connection_limit  	-1
max_connections_per_user *  	-1
agent_refresh  		100
sched_priority  	0 (normal priority)

- ABT

Hi,

Can you try setting Queuing to ON in Default Service.
It will wait for the agents instead of responding back immediatley with No Agents available message.

thanks
Sashanka

quote:

Originally posted by Severus.snape:
Hi,

Can you try setting Queuing to ON in Default Service.
It will wait for the agents instead of responding back immediatley with No Agents available message.

thanks
Sashanka

Will the service have to be restarted?

What other effects does this have in the environment?

- ABT

quote:

Originally posted by Prarie:
Do the reports in question have a -SET &ECHO=ALL; in them?
We have had issues with that error if this setting is left in. Our practice is to move it out after testing is finished.

By all accounts this is a random act, not sure any one report is causing this to die.

Yes restarting the server is required for this change.
There should not be any other effects on the system. We made changes to the num of agents/idle_limit/queuing etc type of settings without any problems.

thanks
Sashanka

I would suggest setting agent_refresh to 1.

This will make the agent kill it self, and a new one will start.

There ar minor overheads with this, but each connection will have a "clean" agent to work with.

You could also increase your number ready from 2 to something a little larger.

quote:

Originally posted by Waz:
I would suggest setting agent_refresh to 1.

This will make the agent kill it self, and a new one will start.

There ar minor overheads with this, but each connection will have a "clean" agent to work with.

I'm reading about this in the help file. The words make sense, but I guess I'm trying to figure out what the deeper meaning is. On the surface, it sounds logical to set low. And to keep high, for that matter. What benefits does a 'clean' agent bring with it? What are the downstream effects? I'm thinking about unintended consequences.

quote:

agent_refresh = positive integer specifying limit for number of new connections

Internal default: 100

This keyword is part of the general workspace features provided in the scope of an agent service. It defines the maximum number of new connections which can be accepted during the life of each agent process. Beyond this limit additional new connections will be assigned to a fresh agent. Agent processes which have reached the limit will be terminated when the last accepted session disconnects.

- ABT

With Agent Refresh set to 100, the agent will be used 100 times. each time the connection finishes, the agent will clear its self out ready for the next connection.

There is a potential that one of the previous connection may leave the agent in an unstable state. e.g. some sort of memory leak or files left behind, etc

I have seen this happen in older version of WebFOCUS. It may not be the case here, but as a rule of thumb, I always set the agent refresh to 1.

Have a look here.

Waz,
As always thanks for the detail in explaining.

- ABT