Artur Hefczyc opened 10 years ago
-
I can make this changes as you suggest but
PepPluginfromTigase XMPP Serverwas not used during tests executed in #3307 as this processor has id of pep-simple. This is simplified PEP support when Tigase PubSub Component is not used or not expected to be used.In test #3307 we used pep processor (@PepPlugin@ from Tigase PubSub Component) and it's performance was tested.
Due to that I do not think we should now take care of
pep-simpleprocessor now, however I can apply changes you suggested. I think looking atpepprocessor would be better as it's performance was not as good as expected in tests from #3307. I'm open for your suggestions for optimizations inpepprocessor (@PepPlugin@ from Tigase PubSub Component project). -
I changed processing of presences by plugin to improve performance and remove from forwarding presences which will not result in sending PEP event messages.
However I do not think it will help a lot as as lot of presence stanzas needs to be forwarded to PubSub component (including presence for offline contacts, etc.)
| Type |
Task
|
| Priority |
Minor
|
| Assignee | |
| RedmineID |
3328
|
| Spent time |
0
|
After code review I find a few places which might need some improvements:
forward method appears to be not used. It may have a bug in the code but instead of fixing the bug we can just remove the method.
processPEPPublish method creates a new Element objects on every method execution. It might be more optimal to have a static field with Element object which is then cloned when necessary.
Message object should be created using tigase.server.Message API. Also, when a Packet object is created (either through Packet API or Message API), passing from, to fields is redundant if these attributes are already set for the Element object. It cases the Packet API to check some stuff and reset them for the Element again.
from.toString() multiple times, might be optimized, or avoided following comments above.
Please take a look at these possible optimizations.