Fastpath issue - user is not shown the offline message (ar agents busy)

Openfire Openfire Support
1

Hi,

I have a little bit of a problem with fastpath. Everything works fine, but one feature. Users are supposed to be shown a busy message if no one accepts their request in a certain time interval. Unfortunately, this doesn’t work with my installation. Even if an agent click on reject, users don’t see a busy messsage.

Here is my configuration of fastpath:

Request timeout: 240s

Expire agent rejection: 20s

Times to overflow before canceling request: 1

I’ll appreciate any help!

Thanks

2

I am seeing the same behavior.

Openfire 3.6.3

CentOS

Fastpath 4.1.0

webchat 4.0.0

After the agent click reject until the time expires, I think its 240 seconds, nothing changes on the client chat request dialog. I just neverendingly waits and tell the user that they are number 1 in the queue and it will be less than 1 minute. If there’s two of us, must be more people experiencing this…

3

Yes… I was thinking if it’d be possible to add some sort of a timer manually so it will display the offline message after some time… I haven’t found a solution yet, though.

4

I actually got it to work! I just reinstalled Openfire and Fastpath, and it worked! Try doing the same thing…

5

Ok… What I found out is that if agents do not reject the requests, but just let them to go away automatically after a certan time (preset in fastpath), then users do get redirected to the offline page. If agents click on “reject” instead of waiting, users never get redirected to the offline page.

6

I removed the FP plugin, dropped all the fp* tables from my db, added all the tables back using the .sql script after installing the plugin, and I get the same behavior you describe. If I just let the messages expire, the customer gets the offline message and can send an email. If I click reject the couple times I am asked, the box tell me I am #1 of 1 in the queue and will get help in 1 minute indefinitely.

So, #1, we are both experiencing this so either our enviros are identical or this is a problem with some of the FP code.

Question #2, how does FP come up with estimated wait times?

7

Oh man, this is strange. Now it works. I can click reject a couple times and after a few minutes I get the timeout message. Crazy.

8

Hmm… This is really odd. Did you do anything to make it work, or it just happened all by itself?

And, thanks for your replies, btw. Its nice to realize that you’re not the only one trying o make it work… =)

And I don’t really show the estimated wait times to users, because I found them to be not very accurate… I guess it just takes a mean value of the wait times of all the requests.

9

I have experienced this issue too on Fastpath. The webchat does not timeout if the request is not explicitly rejected by an agent. The livechat gets stuck in the Routing Request stage.