• AldoRamos

    Heads up: this issue appears to have resurfaced; the same solution still works, but download the latest version: https://github.com/kriszyp/xstyle

    posted in Mango feedback read more
  • AldoRamos

    I didn't find this earlier when searching, but this seems to be similar to unable to discover a bacnet device on my network, specifically in the brief window of apparently successful operation when saving or enabling the publisher.

    posted in User help read more
  • AldoRamos

    We've been experiencing some interesting quirks getting BACnet talking between devices. We have tested between two separate Mango servers, and thought we'd resolved the issue, but when a customer ran into it, (Mango as BACnet publisher, 3rd party software client) I had to dig back in.

    To make a long story medium, our EdgeServer has multiple interfaces:

    • eth0 (Device Area Network) for industrial devices (PLCs, etc)
    • eth1 (LAN/WAN) for interwebz routing
    • wwan0 (4GLTE) for wireless interwebz

    As I was exploring, I noticed that default routes for both eth1 and wwan0. This is to be expected, since both get gateway settings from DHCP. What was unexpected was how the BACnet publisher was horribly unreliable when the wwan0 route had a lower metric (higher priority) than the eth1 route (client is on the LAN with eth1, same subnet). There is no way the gateway route should even come into play when there is an explicit route for the subnet. But when I changed the priorities of the default routes, the results speak for themselves.

    Any thoughts or explanations for this behavior? Suggestions? Has anyone come across this?

    posted in User help read more
  • AldoRamos

    We have a Graphic view that not only summarizes plant operations, but allows the most commonly-used functions (start/stop etc.) to be controlled from that view. This has been operating just fine for a super-admin, but now that we've delegated the control to another user, it does not display the controls. It only displays an hourglass that never resolves to the expected input (binary toggle, numeric input).

    The user has proper permissions, and is able to enter the input on the Data Points page without any problem. It's only on the Graphic view that this problem appears.

    posted in Mango Automation general Discussion read more
  • AldoRamos

    The good news: I finally migrated the data. I think.

    The bad news: I still don't know why java crashes

    In frustration, I finally ran the migration with 1 low-priority thread, and in about 15 minutes, it finally completed — sort of.

    I tried updating java to 1.8.0_152; no effect
    Added 4GB swap (in addition to the 1GB already configured): no effect
    I executed the migration on a VirtualBox VM: no problem, success in about 3 minutes

    Finally, migrated on the server in question with 1 low-priority thread, It executed for 923 seconds — then stopped. I feared it had crashed again, but I noticed mango was still alive, so I checked a few things.

    That's when it got interesting.

    The migration page was seemingly stalled at 19648161 of 38879054
    0_1513389336077_migrate-success.png
    But in the log file, it claimed to have successfully completed:

    INFO  2017-12-15T16:03:36,024 (com.infiniteautomation.nosql.maint.MangoNoSqlMigrationWorkItem.execute:70) - Starting Data Migration, please wait...
    INFO  2017-12-15T16:18:59,072 (com.infiniteautomation.nosql.maint.MangoNoSqlMigrationWorkItem.execute:151) - Migrated 19648161 point values.
    INFO  2017-12-15T16:18:59,072 (com.infiniteautomation.nosql.maint.MangoNoSqlMigrationWorkItem.execute:155) - Finished Data Migration, 19648161 point values migrated to Time Series Datastore took 923.048s
    

    Eventually my eye caught that the 19648161 was (approximately) the same number I had seen in my successful simulation on the VirtualBox instance:
    0_1513391609589_migrate-aldarch.png
    But a quick query on the original db shows:

    MariaDB [mango]> SELECT COUNT(*) FROM pointValues;
    +----------+
    | COUNT(*) |
    +----------+
    | 38879054 |
    +----------+
    

    Curiously, the “successful” migrations show about half the total. I also notice (especially on the actual server) that the total changes a few times during the migration.

    So please help me understand: did the data migrate? Or only half? What am I not understanding?

    The crashing seems obvious to be a java problem, but I can't glean any diagnostic information to pursue further. Note that this instance is running on an Arm architecture, so that might be a factor as well.

    posted in Mango Automation general Discussion read more
  • AldoRamos

    I've noticed a few unexpected log messages, wonder if they give you any clues:

    INFO  2017-12-12T12:11:37,696 (com.serotonin.m2m2.util.DocumentationManifest.parseManifestFile:60) - Documentation manifest file not found: /var/opt/mango/web/modules/dashboardDesigner/web/dox/manifest.xml
    INFO  2017-12-12T12:11:37,505 (com.serotonin.m2m2.util.DocumentationManifest.parseManifestFile:60) - Documentation manifest file not found: /var/opt/mango/web/modules/mangoUI/web/dox/manifest.xml
    WARN  2017-12-12T12:12:23,719 (org.springframework.web.servlet.handler.SimpleUrlHandlerMapping.registerHandlers:114) - Neither 'urlMap' nor 'mappings' set on SimpleUrlHandlerMapping
    INFO  2017-12-12T12:12:25,371 (com.serotonin.m2m2.Lifecycle.configureDwr:1169) - Duplicate definition of DWR class ignored: com.serotonin.m2m2.modbus.dwr.ModbusEditDwr
    

    (edited to include only interesting entries)

    posted in Mango Automation general Discussion read more
  • AldoRamos

    out.sh is linked to ext-enabled generating the 2 log files I posted above, $MA_HOME/logs/ma.out and $MA_HOME/logs/ma.err

    That's what is so puzzling about all this, no error message output whatsoever.

    posted in Mango Automation general Discussion read more
  • AldoRamos

    Wish all problems in life were that easy. ;-)

    Saving it was all it took. Things are back to normal, now.

    Thanks!

    posted in Mango Automation general Discussion read more
  • AldoRamos

    Here is the log from a 2.8 publisher:

    DEBUG 2017-12-11 15:13:17,540 (com.serotonin.m2m2.persistent.pub.PersistentSendThread.sendRealTime:452) - Sending datapoint with index: 1
    DEBUG 2017-12-11 15:13:17,541 (com.serotonin.m2m2.persistent.pub.PersistentSendThread.sendRealTime:452) - Sending datapoint with index: 0
    DEBUG 2017-12-11 15:13:17,541 (com.serotonin.m2m2.persistent.pub.PersistentSendThread.sendRealTime:488) - Publish queue size: 0
    DEBUG 2017-12-11 15:13:20,177 (com.serotonin.m2m2.persistent.pub.PersistentSendThread.sendRealTime:452) - Sending datapoint with index: 7
    DEBUG 2017-12-11 15:13:20,177 (com.serotonin.m2m2.persistent.pub.PersistentSendThread.sendRealTime:452) - Sending datapoint with index: 6
    DEBUG 2017-12-11 15:13:20,177 (com.serotonin.m2m2.persistent.pub.PersistentSendThread.sendRealTime:452) - Sending datapoint with index: 2
    DEBUG 2017-12-11 15:13:20,178 (com.serotonin.m2m2.persistent.pub.PersistentSendThread.sendRealTime:452) - Sending datapoint with index: 3
    DEBUG 2017-12-11 15:13:20,178 (com.serotonin.m2m2.persistent.pub.PersistentSendThread.sendRealTime:452) - Sending datapoint with index: 4
    DEBUG 2017-12-11 15:13:20,178 (com.serotonin.m2m2.persistent.pub.PersistentSendThread.sendRealTime:452) - Sending datapoint with index: 5
    DEBUG 2017-12-11 15:13:20,178 (com.serotonin.m2m2.persistent.pub.PersistentSendThread.sendRealTime:488) - Publish queue size: 0
    DEBUG 2017-12-11 15:13:22,165 (com.serotonin.m2m2.persistent.pub.PersistentSendThread.sendRealTime:452) - Sending datapoint with index: 1
    DEBUG 2017-12-11 15:13:22,165 (com.serotonin.m2m2.persistent.pub.PersistentSendThread.sendRealTime:452) - Sending datapoint with index: 0
    DEBUG 2017-12-11 15:13:22,165 (com.serotonin.m2m2.persistent.pub.PersistentSendThread.sendRealTime:488) - Publish queue size: 0
    DEBUG 2017-12-11 15:13:22,186 (com.serotonin.m2m2.persistent.pub.PersistentSendThread.closeConnection:661) - Sending close packet
    WARN  2017-12-11 15:13:22,187 (com.serotonin.m2m2.persistent.pub.PersistentSendThread.closeConnection:669) - Failed closing SendThread socket.
    java.net.SocketException: Broken pipe (Write failed)
            at java.net.SocketOutputStream.socketWrite0(Native Method)
            at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109)
            at java.net.SocketOutputStream.write(SocketOutputStream.java:132)
            at com.serotonin.m2m2.persistent.pub.TimedOutputStream.write(TimedOutputStream.java:47)
            at com.serotonin.m2m2.persistent.common.Packet.writeHeader(Packet.java:322)
            at com.serotonin.m2m2.persistent.common.Packet.writePacket(Packet.java:280)
            at com.serotonin.m2m2.persistent.pub.PersistentSendThread.closeConnection(PersistentSendThread.java:663)
            at com.serotonin.m2m2.persistent.pub.PersistentSendThread.runImpl(PersistentSendThread.java:267)
            at com.serotonin.m2m2.rt.publish.SendThread.run(SendThread.java:56)
    

    And the Data Source/Listener (3.2)

    DEBUG 2017-12-11 15:19:17,503 (com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT$TcpConnectionHandler.runImpl:557) - /166.176.184.183:4865: ensuring point 105DP_temp, index: 8
    DEBUG 2017-12-11 15:19:17,503 (com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT$TcpConnectionHandler.ensurePointV5:809) - /166.176.184.183:4865: ensuring point 105DP_temp
    DEBUG 2017-12-11 15:19:17,504 (com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT$TcpConnectionHandler.ensurePointV5:817) - /166.176.184.183:4865: point 105DP_temp already exists in RT list
    DEBUG 2017-12-11 15:19:17,504 (com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT$TcpConnectionHandler.updatePointV5:882) - /166.176.184.183:4865: saving point 105DP_temp updates
    DEBUG 2017-12-11 15:19:17,625 (com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT$TcpConnectionHandler.runImpl:567) - /166.176.184.183:4865: confirmed 105DP_temp with client
    INFO  2017-12-11 15:19:17,625 (com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT$TcpConnectionHandler.runImpl:579) - /166.176.184.183:4865: point init done
    INFO  2017-12-11 15:19:17,700 (com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT.run:357) - Received socket from /166.176.184.169:12742
    DEBUG 2017-12-11 15:19:17,768 (com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT$TcpConnectionHandler.runImpl:504) - /166.176.184.169:12742: client requested version 8
    DEBUG 2017-12-11 15:19:17,768 (com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT$TcpConnectionHandler.runImpl:512) - /166.176.184.169:12742: using version 8
    DEBUG 2017-12-11 15:19:17,865 (com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT$TcpConnectionHandler.updatePointHierarchy:960) - /166.176.184.183:4865: updatePointHierarchy
    DEBUG 2017-12-11 15:19:17,874 (com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT$TcpConnectionHandler.updatePointHierarchy:967) - /166.176.184.183:4865: updatePointHierarchy: count=8
    WARN  2017-12-11 15:19:17,874 (com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT$TcpConnectionHandler.run:466) - /166.176.184.183:4865: Connection handler exception
    java.lang.NullPointerException
            at com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT$TcpConnectionHandler.updatePointHierarchy(PersistentDataSourceRT.java:977)
            at com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT$TcpConnectionHandler.runImpl(PersistentDataSourceRT.java:711)
            at com.serotonin.m2m2.persistent.ds.PersistentDataSourceRT$TcpConnectionHandler.run(PersistentDataSourceRT.java:436)
            at java.lang.Thread.run(Thread.java:748)
    

    posted in Mango Automation general Discussion read more