Submitted by Syd Nicholson on Thu, 12/22/2011 - 00:00
Forums
IceBreak

Hi Niels,

I have put in place a temporary method for a client's users to remote power up their systems. Works a treat. I look forward to your update to IceBreak - please keep me informed. Many thanks once again.

My client has another problem which I am at a loss to explain. The system seems to starting many extra sessions. There is definitely a performance issue. For example if the process is slow - they try again - and this seems to spurn another session. This morning a user had logged on from a single PC, only the once, in a single browser session.  He must have been constantly trying things because he had 5 active sessions in the IceBreak subsystem. The problem with this is:

1. If a request is made to the server, it does not connect to the right session and things go wrong.
2. Users lock themselves out of records for update, messages appear in QSYSOPR, the response stops and things escalate.

Is it possible to stop these additional sessions starting?

Part of the problem, I admit, is that the SQL I am using is far too slow and If I go on like this a more powerful machine is going to be required. In correcting some of the problems I am going to have to remove the SQL and replace it with Native DB access in RPG. Also, part of the problem is that SQL does not close the access path when finished - this leaves files constantly open, and therefore problems if anything requires exclusive file access.

Another problem, is that users seem to get logged out unexpectedly. I suspect this is happening because another session is being started under the default BLUEBOXUSR.

Too many sessions session are being started, there is a maximum of approx 20 users at best,the vast majority of these users have only one browser session.  Yet close to 80 sessions are active in the IceBreak subsystem. Where do all the extra IceBreak sessions come from?

Niels Liisberg

Thu, 12/22/2011 - 00:00

Permalink

Hi Syd,

It is correct that, if IceBreak can not obtain a connection to the job serving the session – then it spawns a new job to replace the first; and – Yes; you will have these experiences you describe.

You have two options:

  1. Change you programs to have a fast user response :) … this can be a challenge (I know)
  2. Yo can experiment with the new dispatcher method  *SHAREDPOOL   
    The SHAREDPOOL will reuse the same job (jobs) for all request. You don't have a dedicated job for each session in that mode – you need to store your session data in the session object only.

Also ensure you have the latest IceBreak version installed, and if the problem reoccurs please don't hesitate to contact out excellent support team and let one of these guys have a look at your system.