Xep 136 of monitor plugin doesn't work in openfire 3.10.2

Openfire Plugins Community Plugins
21

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)

22

I have filed this https://igniterealtime.org/issues/browse/OF-1078

1 Like
23

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.

24

I found the issue in the code, I’ll make a fork and post a link.

25

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.

26

Thanks Junius!

27

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?

28

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”

29

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.

30

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
31

it would be awsome if you could share your fix!

32

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.

33

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)