Submitted by Anonymous (not verified) on Wed, 05/28/2014 - 00:00
Forums
IceBreak

Hi,

I have a request from a customer and I was wondering if you could help me. This is the customers request:
It appears it takes a few seconds for the session to end (after the call to the webservice completes), and if another request is sent during this time then the session remains open. As soon as sesEnd() is called it should stop accepting requests

I don't know why the customer wants a new job for each and every incoming web service request. To me this would be an inefficient use of resources, repeated job end and job starts etc... , but this is what they have asked for so I had to pass this request on.

A parameter might do the trick, however, if this is not possible then I'll tell them that and close the support ticket.

Niels Liisberg

Wed, 05/28/2014 - 00:00

Permalink

Hi;

The problem is that we may create a monster if we implement it. Let me explain:

The reason why the IceBreak application server job continues a couple of seconds after a sesEnd() is issued, is to let the server finally request for i.e. a log on screen if you signoff. IceBreak assumes that it will be the last thing done and terminates the connection with the frowned IceBreak web server.

Now – if you use sesEnd() with a SOAP service – then you are using a hammer as a screwdriver: SOAP is by definition stateless and has no sessions assigned.

On the other hand – IceBreak supports sessions by url – so you can actually dedicate a private service for your client and this will be session stable – and the sesEnd() will work as designed – because there will be no requests after the sesEnd() is issued.

To implement that, simply let the client generate a session along the url. This is constructed as a time stamp without delimiters, so: http://myibmi:8080/MySoap.asmx

Will be:
http://myibmi:8080/.20140530112233999999/MySoap.asmx

So the .20140530112233999999 part is a session ID generated by the client…

The reason why we are not to happy about allowing sesEnd() in SOAP is the limbo-land we can run into; If the session ends – at the same time as the frontend verifies that a job is ready to receive the request – you will have a dangling situation: No job to serve the client and the client will just wait for a response. All lights on – but nobody is home.

Best regards,
Niels Liisberg