It’s about 3 months and there is still no fix.
I think it is big problem of mam (xep-0313) implementation in xep-0313 implementation · igniterealtime/Openfire@4dfa5f4 · GitHub
This patch broke xep-0136 and archiving conferences Monitoring plugin is failing to archive messages in mysql for MUC rooms
I agree with Alex that it is connected with database and SQL requests.
But I don’t understand why unstable 1.4.7 from ‘master’ included in 3.10.2 distro? While 1.4.5 from ‘3.10’ branch does not have such problems.
Andrey,
Currently, our bamboo build host only builds plugins out of the master branch and is not pointed at 3.10 branch. A long standing issue is that plugins are on their own timeline than openfire’s code. The only association is within the plugin.xml to specify minversion. It would be nice to fix this, but it would take a bunch of effort to add logic on the website, within openfire, and have devs that are willing to maintain a branch and master version’s of their plugins. We are very short on volunteers at the moment.
daryl
How can I have source code of monitoring plugin 1.4.6 ? It was working for me!!!
Hello,
for me Openfire 3.10.3 with monitoring 1.4.4 was working. any other combination did not.
i tried now upgrading to openfire 4.0.1 and upgraded all plugins…(also monitoring to 1.5).
Same error again when retrieving history:
2016.01.31 11:56:12 org.jivesoftware.openfire.handler.IQHandler - Internal server error
java.lang.NullPointerException
at com.reucon.openfire.plugin.archive.xep0136.Xep0136Support$1.handleIQ(Xep0136Sup port.java:40)
at org.jivesoftware.openfire.handler.IQHandler.process(IQHandler.java:66)
at org.jivesoftware.openfire.IQRouter.handle(IQRouter.java:372)
at org.jivesoftware.openfire.IQRouter.route(IQRouter.java:115)
at org.jivesoftware.openfire.spi.PacketRouterImpl.route(PacketRouterImpl.java:78)
at org.jivesoftware.openfire.SessionPacketRouter.route(SessionPacketRouter.java:10 8)
at org.jivesoftware.openfire.SessionPacketRouter.route(SessionPacketRouter.java:67 )
at org.jivesoftware.openfire.http.HttpSession.sendPendingPackets(HttpSession.java: 639)
at org.jivesoftware.openfire.http.HttpSession$HttpPacketSender.run(HttpSession.jav a:1270)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
So monitoring-plugin still seems broken. No surprise as it’s still the 1.5 version.
But for everyone interested: Openfire 4.0.1 seems to work with monitoring-1.4.4 (build Openfire-3.10.0 to get monitoring-1.4.4 )
then install it on Openfire-4.0.1.
1 Like
Hi toni,
Thank you for the detailed and helpful information. With monitoring 1.4.4, what database were you using? I don’t currently have an environment set up. Would you be able to send me a jar for monitoring 1.4.4?
Thank you,
Matt
Hi Matt,
i use openfire with mysql (5.5.47). attached is the monitoring-1.4.4 built i made. hope it helps.
cheers
Toni
monitoring.jar (4833743 Bytes)
1 Like
Hi Toni,
Thank you. Unfortunately, 1.4.4 has the same issue I’ve been dealing with. XEP 136 does not work when using Microsoft SQL Server as the external database. It looks like the plugin has had issues with MS SQL Server in the past (issue OF-755 resolved by Daryl Herzmann). Can anyone add this to JIRA?
Here’s the error log (using Openfire 4.0.1 and Monitoring Service 1.4.4):
2016.02.01 10:31:29 org.jivesoftware.util.Log - Error selecting conversations
java.sql.SQLException: An expression of non-boolean type specified in a context where a condition is expected, near ‘RowNum’.
at net.sourceforge.jtds.jdbc.SQLDiagnostic.addDiagnostic(SQLDiagnostic.java:372)
at net.sourceforge.jtds.jdbc.TdsCore.tdsErrorToken(TdsCore.java:2988)
at net.sourceforge.jtds.jdbc.TdsCore.nextToken(TdsCore.java:2421)
at net.sourceforge.jtds.jdbc.TdsCore.getMoreResults(TdsCore.java:671)
at net.sourceforge.jtds.jdbc.JtdsStatement.executeSQLQuery(JtdsStatement.java:505)
at net.sourceforge.jtds.jdbc.JtdsPreparedStatement.executeQuery(JtdsPreparedStatem ent.java:1029)
at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.logicalcobwebs.proxool.ProxyStatement.invoke(ProxyStatement.java:100)
at org.logicalcobwebs.proxool.ProxyStatement.intercept(ProxyStatement.java:57)
at $java.lang.AutoCloseable$$EnhancerByProxool$$416dbe86.executeQuery()
at com.reucon.openfire.plugin.archive.impl.JdbcPersistenceManager.findConversation s(JdbcPersistenceManager.java:234)
at com.reucon.openfire.plugin.archive.xep0136.IQListHandler.list(IQListHandler.jav a:49)
at com.reucon.openfire.plugin.archive.xep0136.IQListHandler.handleIQ(IQListHandler .java:34)
at com.reucon.openfire.plugin.archive.xep0136.Xep0136Support$1.handleIQ(Xep0136Sup port.java:48)
at org.jivesoftware.openfire.handler.IQHandler.process(IQHandler.java:66)
at org.jivesoftware.openfire.IQRouter.handle(IQRouter.java:372)
at org.jivesoftware.openfire.IQRouter.route(IQRouter.java:115)
at org.jivesoftware.openfire.spi.PacketRouterImpl.route(PacketRouterImpl.java:78)
at org.jivesoftware.openfire.net.StanzaHandler.processIQ(StanzaHandler.java:342)
at org.jivesoftware.openfire.net.ClientStanzaHandler.processIQ(ClientStanzaHandler .java:99)
at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:307)
at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:199)
at org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandl er.java:181)
at org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceive d(DefaultIoFilterChain.java:690)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(D efaultIoFilterChain.java:417)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilt erChain.java:47)
at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceiv ed(DefaultIoFilterChain.java:765)
at org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapte r.java:109)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(D efaultIoFilterChain.java:417)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilt erChain.java:47)
at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceiv ed(DefaultIoFilterChain.java:765)
at org.apache.mina.filter.codec.ProtocolCodecFilter$ProtocolDecoderOutputImpl.flus h(ProtocolCodecFilter.java:407)
at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecF ilter.java:236)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(D efaultIoFilterChain.java:417)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilt erChain.java:47)
at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceiv ed(DefaultIoFilterChain.java:765)
at org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:74)
at org.apache.mina.core.session.IoEvent.run(IoEvent.java:63)
at org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTask(Ordere dThreadPoolExecutor.java:769)
at org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTasks(Order edThreadPoolExecutor.java:761)
at org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.run(OrderedThr eadPoolExecutor.java:703)
at java.lang.Thread.run(Unknown Source)
Thanks Daryl. Note that XEP 136 has not been working at all since Monitoring Service 1.4.6 as noted at the beginning of the thread, so that will have to be resolved first.
I found the issue in the code, I’ll make a fork and post a link.
OK, I made the changes and sent a pull request (didn’t work on the MSSQL issue though).
You can clone my repo to build the plugin manually :
GitHub - n00dl3/Openfire: A XMPP server licensed under the Open Source Apache License.
Thanks Junius!
Hello,
I still with openfire 3.10.3 and monitoring 1.4.21 (1.4.2 with fix for OF-812, but this fix seems wrong) and 1.4.4
1.4.21 still returns all conversations regardless of startDate parameter. As I can see in sources this place fixed only in this year.
1.4.4 works OK in this sense but very slowly
Is there some newer version of plug-in that can work with 3.10.3?
I do not upgrade because I’ve read that openfire 4 does not support XEP-0136. Or may be this is false alarm?
monitoring basically works for me with openfire 4.
in case you use strophejs you will have to check if strophejs sets the right namespace.
must be “urn:xmpp:archive:auto” not “urn:xmpp:archive”
Yesterday I was forced to study how to build openfire and plugins, find bug in 1.4.2 related to startDate value(OF-812), fix it at last and compile own version of 1.4.2.
After day of testing I can say that it works almost fine.
About 1.4.4. - authors changed SQL queries in it, as I can understand to make results sorting by time by DB itself.
In my case: VM under HyperV on dual Xeon E5 2620 v2 (2.1GHz) 32 GB RAM. In guest system - 10 cores.
Archive loading by one miranda produces 3-4 messages every 3 seconds. During this MySQL fully loads one core (10% CPU), so I guess this slow process is because DB overload or may be badly configured(help is very appreciated - I’m dumb in DBs).
My 1.4.2 version produces about 100(or more) messages per second without any significant CPU using.
Woohoo, I’ve changed 1.4.2. so it returns chats sorted by srtartDate! May be ugly solution but it works and works fast.
I’m happy
1 Like
it would be awsome if you could share your fix!
Hi, I am finding the Monitoring Service plugin with version 1.4.6 or 1.4.7, could you guys share with me if you have?
Thanks a lot.
Sorry, I did not see you message.
I’ve attached monitoring plug-ing using by me now
It based on version 1.4.3
I’ve fixed sorting and secs attribute calculation https://community.igniterealtime.org/docs/DOC-2822#comment-10943
monitoring_1.4.3.6(Davis).zip (4823194 Bytes)