I have been trying out Fastpath 4.1.0 along with Openfire 3.6.4, Fastpath Webchat plugin 4.0.0 and Spark 2.5.8
I have the out of the box demo workgroup and default queue set up, a single agent logged in via Spark with a maximum of 1 session configured.
If I queue up 5 requests from different browsers using the web chat plugin, I observe the following:
The first request is offered immediately as expected.
I accept this and then close the chat session.
Now the remaining requests are not offered in the order that they were raised. E.g. The 5th raised request was offered next (the web chat window actually says “you are in position 5 in the queue” or similar).
This means that the customer that was added to the queue last is served before the customer that was added 2nd, which seems wrong.
Is this a bug or have I set something up incorrectly? I’ve checked the docs and searched for existing posts on this but haven’t found anything, but seems like a major issue if this problem scales to a much larger queue.
Thanks.
Try setting debug logging in Openfire, then rerunning the tests. It should explain more clearly what is going on with the connection requests and assignments.
Thanks, gave this a try. It looks like the server tries to route all of the requests which enter the queue at once, rather than ensuring they are correctly routed in queue order (i.e. guarantee that the request at the head of the queue is routed first).
I wrote a java client which uses Smack to put a bunch of requests into the queue, to see what happens. A small excerpt from the server log:
2010.08.15 19:59:33 InternalComponentManager: RR - Agent: demo@stuart-chalmerss-macbook.local/spark MAY NOT receive offer for request: org.jivesoftware.xmpp.workgroup.request.UserRequest@3d8c4d8e
2010.08.15 19:59:33 InternalComponentManager: RR - Agent: demo@stuart-chalmerss-macbook.local/spark MAY NOT receive offer for request: org.jivesoftware.xmpp.workgroup.request.UserRequest@22bc6389
2010.08.15 19:59:33 InternalComponentManager: RR - Agent: demo@stuart-chalmerss-macbook.local/spark MAY NOT receive offer for request: org.jivesoftware.xmpp.workgroup.request.UserRequest@15e3f46
2010.08.15 19:59:33 InternalComponentManager: RR - Agent: demo@stuart-chalmerss-macbook.local/spark MAY NOT receive offer for request: org.jivesoftware.xmpp.workgroup.request.UserRequest@729405ca
2010.08.15 19:59:33 InternalComponentManager: RR - Agent: demo@stuart-chalmerss-macbook.local/spark MAY NOT receive offer for request: org.jivesoftware.xmpp.workgroup.request.UserRequest@4d1d54a5
2010.08.15 19:59:33 InternalComponentManager: RR - Agent: demo@stuart-chalmerss-macbook.local/spark MAY NOT receive offer for request: org.jivesoftware.xmpp.workgroup.request.UserRequest@64650ddb
2010.08.15 19:59:34 InternalComponentManager: RR - Agent: demo@stuart-chalmerss-macbook.local/spark MAY NOT receive offer for request: org.jivesoftware.xmpp.workgroup.request.UserRequest@6c977c1f
2010.08.15 19:59:34 InternalComponentManager: RR - Agent: demo@stuart-chalmerss-macbook.local/spark MAY NOT receive offer for request: org.jivesoftware.xmpp.workgroup.request.UserRequest@59dccc75
This seemed to confirm this so I had a look at the source code, which led me to org.jivesoftware.xmpp.workgroup.dispatcher.RoundRobinDispatcher. From the quick look I had it seems the server tries to dispatch all outstanding requests in a separate thread (i.e. disregarding the queue order and imposing an arbitrary order).
To me this behaviour seems incorrect (i.e it isn’t a queue at all). If I was a customer and knew that someone behind me in the queue was served first, I’d probably be upset!
I may have misunderstood something, so if anyone can shed any more light I’d really appreciate it.
Thanks
Your explanation does sound correct, and I think Fastpath is better suited for low traffic situations. Probably adding some thread management or synchronized blocks may be of use.