I’‘m new here i’‘ve just downloaded and tested your jabber server and found those two bugs/features (before posting i’'ve searched thru the forum and found nothing similar):
First one: when you limit possible number of connection to database to one some strange effect occurs (tested on postgresql):
there is no way to add anyone to your roster (there is massage that everything went ok, but in roster and database nothing appears)
when you select database option in admin console server freezes and must be restarted
if someone has anyone in roster connection to server is impossible (and server freezes also)
Second one: it appears when you have client with auto authorization feature enabled
suppose admin sends broadcast -> user receives it and adds server to roster as (server)
now if user sends authorization to this contact loop of death occurs (let say authorization ping-pong)
if you send authorization request to this user (server) it responds with authorization request from my user so my client adds it and authorizes it. And now loop occurs because server responds to this authorization with two messages: authorization granted and another authorization request…
Welcome to the forums, and thanks for your bug reports!
First one: when you limit possible number of
connection to database to one some strange effect
occurs (tested on postgresql):
A good minimum size for the connection pool is probably 5. We should enforce that minimum size in the setup tool. I’'ll file that as an issue…
Second one: it appears when you have client with auto
authorization feature enabled
suppose admin sends broadcast → user receives it
and adds server to roster as (server)
now if user sends authorization to this contact
loop of death occurs (let say authorization
ping-pong)
if you send authorization request to this user
(server) it responds with authorization request from
my user so my client adds it and authorizes it. And
now loop occurs because server responds to this
authorization with two messages: authorization
granted and another authorization request…
I believe a similar issue was reported, specifically for Psi. That issue is in progress as JM-288. Your additional info may help us track it down faster, though.
OK Lets reproduce the second one step by step in clean environment:
Start the server
Start the client
Create new user (Account Setup->Add with register new account…)
Log in to server (you can publish your vCard but it isn’'t really required)
Log out
Make sure that Options->Events->Auto-Authorize contacts is checked (if you change it now please restart PSI as this change won’'t be honored)
Log in to the server
Now Actions->Add User and choose that you’'ve just created (checkbox - request authorization when adding should be checked)
Clicking add starts the process
Switching option Auto-Authorize off and doing these steps may provide us with information why this has just happened:
steps 1-5 remain the same…
Make sure that Options->Events->Auto-Authorize contacts is NOT checked (if you change it now please restart PSI as this change won’'t be honored)
steps 7 and 8 like last time
Click add
Client just receives authorization-request
Respond with Add/Auth
Now we have another two messages; the first one is Authorization-Request and the second one is info that the request from point 10 was answered with Auth (basically Authorization-granted message)
So question is why there is second Authorization-Request (from point 12)
hm… and why do you want/have to add contacts by yourself? there is a nice server-side roster management with shared groups in JM, actually this is one of killer features of JM. Or i dont understand something:)
management with shared groups in JM, actually this is
one of killer features of JM. Or i dont understand
something:)
Shared groups are great (as are the admin console and the broadcast plugin)!
we’‘ve only been using them in a ‘‘global’’ context, i.e. everyone can see all groups, but as we have chosen Psi (to be consistent across several OSes), we can’‘t add contacts into multiple groups via the client GUI, even though it supports the concept. Your question has caused me to take a closer look at group management to overcome this client shortfall as several users want to have ‘‘private’’ groups that aren’'t necessarily useful to everyone.
You guys think of everything
This multiple group facility is apparently slated for the next Psi release.