Hello!
I thought that upgrading from 3.1.0 to 3.2 release will stop the presence problems on my dual homed server.
But sorry to say, NO, my Spark 2.0.8 still shows users as online although the have logged out successfully minutes ago or dont show users as online although they are for quite some time.
My reference is the sessions tab of the web admin. where they show up correctly.
I never noticed this with users on the same subnet, it only has troubles keeping track of users on the other subnet.
Logging Out and reconnecting Spark always updates the status to the correct values…
P.S. Besides very seldom file transfer probs (see other post) all the other features do work perfectly so I dont think of a configuration error…
Any ideas?
Bye
Starry
I’‘ve had the same problem for several months now. My watch list includes four threads from other users with similar problems, and unfortunately they’'ve gone completely unnoticed and unresolved. I was hoping that 3.2 would fix the problem and I could get our office using our Wildfire server, but I guess not.
I’‘m seeing this issue as well, it’‘s disappointing as it’‘s such a great product and i’‘m so close to selling the enterprise plugin to a client but until this issue is solved I can’'t. Any updates on this?
Message was edited by: csteven
Hey guys,
Yesterday we were able to fix JM-972 which could be your case. You can try using the nightly build version that includes the bug fix. If this is not your case then we will need to hear from you the steps/configuration to use to reproduce the presence problem. As you can see in JM-972 the setup was not easy to figure out.
Regards,
– Gato
Hello!
Thanks alot, I will try.
My setup however is a little easier:
-
Users of Group E (externals) are NOT shared but simply grouped.
-
Users of Group T (Team) are shared to their own members (default) as well as to Group E.
-
So Group E (external customers) can see all the available Support TEAM Guys and TEAM mate do see each other (also literally as the sit in the same room!)
-
Some of the T boys added E customers to their roster for having some chat. Now things go wrong!
(BTW When doing so user e of Group E does not get asked for permission! Guess this is because Wildfire is democratic and think it is OK, as the presesence is shown the other was around due to Group T being shared!!!)
The problem: The presence of the E boys is perfectly updated into the WebGui but dont make it to the T desktops. To be more exact it seems that they miss presence CHANGES of the Externals. When new E boys come online the T does not see this. Also E guys leaving stay online in the T roster.
If the supporter T logges out and back in, everything is fine again.
Just for added info: When opening a chat window also the chat window claims away, although the two are chatting like hell. Only file transfer attempts seem to believe in this (wrong) presenence. File transfers dont work with the message “the other is not online!”
Hope it helps.
Starry
Hey Starry,
Thanks for the detailed steps to reproduce this problem. It does seem to be a different case so it may not be fixed with the previous bug fix. I will try to reproduce it locally and get back with news.
Regards,
– Gato
Hello!
Is my case one which is covered by jm-985 ??
Bye
Starry
Hey Starry,
When I fixed JM-985 I didn’‘t have in mind this case. You can see the covered cases in the description of the Jira issue. I don’'t think that fix solved this problem. I will check it now and see how it works.
Regards,
– Gato
Hey Starry,
I just reproduced this case. It works fine only when you make the manual subscription and never restart the server. But if you restart the server (or for some reason the roster or a member of GroupE has to be loaded again) then it is broken. I will try to fix it now.
Thanks,
– Gato
Hello!
Just to update everybody. Gato said in the last weekly chat, and pls correct me if I misunderstood:
This one is very tricky and not catchable by the current implementation of the shared group model within wildfire.
I guess I am not alone really requesting this feature. One of the major differenciations to other jabber server implementations is the flexibility of Wildfires server side shared groups. However with killers like this or things like JM-802 (which also seem to be not possible with the current codebase) a siginificant part of this so called flexibility is actually not working.
I kinow, this may sound harsh but pls dont take it personal, you Jive guys!!
Bye
Starry
Hello!
Although you said you will not fix this in the near future would you mind entering it into JIRA so we could track the issue and at least vote for it? thanks.
Starry
Hey Starry,
The bug described in this thread has been filed as JM-1025. As Gato said, both this issue and JM-802 will require some re-specification of the way Shared Groups work.
Cheers,
Greg
Hi!
Thanks for entering into JIRA and also thanks for making the important differenciation between JM-802 which almost all users also consider to be a bug but could “discussable” whereas this one is a clear bug of presence not being forwarded to the clients correctly.
Dont wanna “throw oil into the fire” as we say over here but it does not look like “re-specification ofd the shared groups” but rather a “re-implementation” as both cases are valid usage scenarios and can be setup via the web gui without any tricks.
Anyway I keep my fingers crossed that some of the big boys stumble across this so you are able to put some ressources into it.
Bye
Starry
Hello!
Just a reminder for everybody reading, that you can (and should?) vote for JM-1025.
Bye
Starry