Paweł Chmielowski
Paweł Chmielowski
This should be fixed by a3265f5d702fcac045add37aa7b526e884b15022
Yes indeed there is no sharing token assignments between nodes in this module, so you could be only be able to perform upload on node where slot allocation was performed....
Could you see open that crash log in editor and look for line with 'Stack+heap: 850246556' and then copy here lines starting from '=proc:' before that line, to next '=proc'?
Could you also please copy paste section for =proc:
Hm, so it looks like you process that overflows memory is, one spawned to handle http api call. and it possibly did that when trying to see if you have...
Only thing from that possibly could have that impact, could possibly be using shared_group in acl rule, depending how that group is defined, getting data about that group could somehow...
As i said i never seen anything like that before, and i think in general your current setup should be ok. But shared rosters can have impacts on bigger installations,...
Hm, now that definitely strange behaviour, i don't remember seeing anything like that before, will have to test and see if this is reproducible here.
So i tried to reproduce that, and no matter how i configured ip blocking, i never did get oom - i always was getting error like you see there.
Hello, Do you know what older version of ejabberd you had installed? I think there should be dpkg.log in /var/log somewhere that should show info that contain this.