Hi Joacim,

 

If you use the java.lang.Thread.currentThread().sleep(10000);  statement, the current thread is halted for 10 seconds. I have limited knowledge in this specific area,  but it might be that the other XPage calls are/ should be processed by the same thread and therefore won't be processed until the 10 seconds have passed.

I don't know what you're exactly trying to do, but from what you've described I would suggest another approach: let the client (browser) handle the check-intervals. Using the javascript setInterval function you can let the browser perform a certain action (e.g. Ajax call) until it's not needed anymore.

 

Mark

 

 

 Hi there Mark!

 

 

Yes, it seems so. The behavior is  identical to when you've haven't set your agents to be able to run concurrently. An option we've had for several years with ordinary Agents...

This seems as a huge step back in my eyes, that you're only able to run ONE XPage at a time per session. (From what I understand there's only one thread per session allowed, hence this behavior.) 

 

Long AJAX polling is a common frontend technique to improve performance. Gmail is using it, among several others. Basically you issue one AJAX request and that request is live until the server returns something. If your criteria is fulfilled server-side the data is returned to the AJAX request (this thread finishes) and a new AJAX request is issued and it starts all over again. This way you don't have to hammer the server witch requests every X seconds just to see if something new has happend.

 

 

Because of the above I had to revert to setTimeout (a pattern of setTimeout is in general preferred as it will only issue a new request as the first one has finished, setInterval may introduce a race condition).

 

 

This works, but it's not an elegant solution.

 

 

Love your blog by the way! Keep it up! =) 

 

 

/J 

Hi!

 

Please take a look at my response in this thread of this forum:
http://www-10.lotus.com/ldd/xpagesforum.nsf/topicThread.xsp?documentId=F9B69B2341F84051852578C3003A50BE&action=openDocument

 

Might be a workaround for this limitation.