Great questions.  I've responded inline below:

On Friday, March 25, 2016 at 6:52:09 AM UTC-5, Matthew Wild wrote:
>
> Hi Aaron, 
> [snip]
>
> Just to confirm, are you saying 0.10 build 181 works, and 182 does 
> not? (for the record, that seems unlikely) or is the exact build that 
> breaks unknown? 
>
>
I had 0.10 build 181 working.  I think tried the latest prosody-trunk at 
the time (625).  I experienced this failure mode. I then attempted to 
upgrade to the latest 0.10 build and experienced the same errors.  You are 
correct that I haven't tested every single build in between, but if needed 
I am happy to start exploring in which versions the error began to occur. 
 It certainly exists in the latest 0.10 and trunk builds.

 [snip]

>
> What authentication and storage backends is Prosody configured to use? 
> These are the most likely candidates for this kind of behaviour. 
>

I am using anonymous authentication for users on the vhost, and 
internal_hashed for server-wide behavior.  I am using the interal storage 
mechanism.

[ snip ]
> You mention using other modules (I guess the prosody-modules repo?) - 
> which of these modules are you using, and any chance that it could be 
> an issue in one of these rather than Prosody itself? 
>
>
Thanks for suggesting modules.  I will attempt to run these tests without 
any non-required modules enabled, and see whether the behavior changes.

The modules I am using are:

Global modules: 

roster
saslauth
tls
dialback
disco
posix
register
admin_adhoc

pubsub
adhoc
websock
http_altconnect
bosh

For my main vhost:

bosh
pubsub
ping


For the conference domain:
muc_hide_all
muc_max_occupants

These last two are custom modules we developed to hide all rooms, and limit 
the number of participants in a room to some maximum.

 

> [snip]
>
 

> No particular change springs to mind (apart from SQL changes, as 
> mentioned above). 
>
> Prosody appearing to freeze momentarily will either be caused by 
> something CPU intensive (e.g. a loop), or by some syscall that blocks. 
> The former should be detectable with most standard monitoring tools. 
> The latter could be caught with something like strace or sysdig. 
>
>
I will continue to attempt different techniques to monitor the prosody 
process and see whether I can try to track down this failure.

Thanks again for your suggestions.

Cheers,

-Aaron


 

> Regards, 
> Matthew 
>

-- 
You received this message because you are subscribed to the Google Groups 
"prosody-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to prosody-dev+unsubscr...@googlegroups.com.
To post to this group, send email to prosody-dev@googlegroups.com.
Visit this group at https://groups.google.com/group/prosody-dev.
For more options, visit https://groups.google.com/d/optout.

Reply via email to