configuration of/filtering email alerts

[shaun]

Hi @phildunlap

Can you provide further assistance with the above error I'm seeing and questions?

Cheers!
-Shaun

[phildunlap]

Hi Shaun

That's strange! I was not able to reproduce. Did it print a stack trace out to your console or log? The only thing I can imagine that being is the escalation scheduling. If you check the escalation box using the UI, what does it display for the time period of the escalation delay? I suspect we've fixed the underlying issue in the latest core version.

Bulk updating can be tricky to pick the 'best' way. Find/replace is often sufficient and fast, sometimes going through the UI will be fastest. Doing this JSON scripting stuff, you can use the same code to load your configuration, and the same code to write the output (only use myConfig instead of outputConfig) and you will write out the whole of your configuration again, but altered by whatever loops come in between.

To run a bulk delete (which doesn't happen often, usually it's a data source that needs deleting, where the UI will do well), I generate SQL.

ouputSQL = "DELETE FROM dataPoints WHERE xid IN ("
for dp in myConfig["dataPoints"] :
    if dp["deviceName"] == "So long, this device!" :
        outputSQL += "'" + dp["xid"] + "',"

if "," in outputSQL :
    outputSQL = outputSQL[:-1] + ");"
    print outputSQL

else :
    print "No Points matching device name"

and while that would be the same as...

DELETE FROM dataPoints WHERE deviceName='So long, this device!';

... it's a more flexible abstraction (but it's rare you need granular delete control in my experience, unless you make a bad mistake during a big generation!)

[shaun]

Hi Phil,

Thanks for your help...

The export; find/replace; import method is something I've done before to good effect... The SQL for bulk deletion is something that I was really not sure of... thanks!

The error I'm seeing does produce something in the log:...

com.serotonin.ShouldNeverHappenException: Unsupported time period: 0
	at com.serotonin.m2m2.Common.getPeriodDescription(Common.java:266)
	at com.serotonin.m2m2.rt.event.type.AuditEventType.maybeAddPeriodChangeMessage(AuditEventType.java:189)
	at com.serotonin.m2m2.vo.event.EventHandlerVO.addPropertyChanges(EventHandlerVO.java:566)
	at com.serotonin.m2m2.vo.event.EventHandlerVO.addPropertyChanges(EventHandlerVO.java:46)
	at com.serotonin.m2m2.rt.event.type.AuditEventType.raiseChangedEvent(AuditEventType.java:94)
	at com.serotonin.m2m2.db.dao.EventDao.updateEventHandler(EventDao.java:685)
	at com.serotonin.m2m2.db.dao.EventDao$8.doInTransactionWithoutResult(EventDao.java:665)
	at org.springframework.transaction.support.TransactionCallbackWithoutResult.doInTransaction(TransactionCallbackWithoutResult.java:34)
	at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:133)
	at com.serotonin.m2m2.db.dao.EventDao.saveEventHandler(EventDao.java:659)
	at com.serotonin.m2m2.db.dao.EventDao.saveEventHandler(EventDao.java:654)
	at com.serotonin.m2m2.web.dwr.EventHandlersDwr.save(EventHandlersDwr.java:286)
	at com.serotonin.m2m2.web.dwr.EventHandlersDwr.saveEmailEventHandler(EventHandlersDwr.java:255)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:483)
	at org.directwebremoting.impl.ExecuteAjaxFilter.doFilter(ExecuteAjaxFilter.java:34)
	at org.directwebremoting.impl.DefaultRemoter$1.doFilter(DefaultRemoter.java:428)
	at com.serotonin.m2m2.web.dwr.util.TranslationsFilter.doFilter(TranslationsFilter.java:37)
	at org.directwebremoting.impl.DefaultRemoter$1.doFilter(DefaultRemoter.java:428)
	at com.serotonin.m2m2.web.dwr.util.ExceptionDetectionFilter.doFilter(ExceptionDetectionFilter.java:26)
	at org.directwebremoting.impl.DefaultRemoter$1.doFilter(DefaultRemoter.java:428)
	at com.serotonin.m2m2.web.dwr.util.DwrPermissionFilter.doFilter(DwrPermissionFilter.java:45)
	at org.directwebremoting.impl.DefaultRemoter$1.doFilter(DefaultRemoter.java:428)
	at org.directwebremoting.impl.DefaultRemoter.execute(DefaultRemoter.java:431)
	at org.directwebremoting.impl.DefaultRemoter.execute(DefaultRemoter.java:283)
	at org.directwebremoting.servlet.PlainCallHandler.handle(PlainCallHandler.java:52)
	at org.directwebremoting.servlet.UrlProcessor.handle(UrlProcessor.java:101)
	at org.directwebremoting.servlet.DwrServlet.doPost(DwrServlet.java:146)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:808)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1669)
	at org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83)
	at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:300)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
	at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
	at org.eclipse.jetty.server.Server.handle(Server.java:499)
	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
	at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
	at java.lang.Thread.run(Thread.java:745)

Screenshot of what I submitted to generate the error is below. This was just editing the existing event handler.

I tried setting the escalation on as you suggest (in the screenshot), and I get the exact same error.
Email alerts do seem to be working though... I've had a few come through over the last few days via the mailing list.

This is the event handler configuration I imported to create the initial event handler:

{
            "includePointValueCount": 10,
            "activeRecipients": [
                {
                    "recipientType": "MAILING_LIST",
                    "mailingList": "ML_CRAC"
                }
            ],
            "xid": "EH_CRAC1_U1_Airflow_Alarm",
            "includeSystemInformation": false,
            "eventType": {
                "dataPointXID": "DP_CRAC1_U1_Airflow_Alarm",
                "sourceType": "DATA_POINT",
                "detectorXID": "PED_CRAC1_U1_Airflow_Alarm"
            },
            "sendInactive": true,
            "sendEscalation": false,
            "disabled": false,
            "alias": "CRAC1 - Unit 1 Airflow Alarm",
            "handlerType": "EMAIL",
            "inactiveOverride": false,
            "includeLogfile": false
        },

Cheers!
-Shaun

[phildunlap]

Thanks for providing so much detail!

It does look like that issue was fixed in 2.8 so upgrading is one path to resolution.

I see it does indeed have to do with the escalation period! You could try reimporting your generated JSON with "escalationDelayType": "HOURS" but that may not work. If it doesn't, you'll unfortunately have to import new handlers with that property set to begin with, and probably delete the first batch (which is one of the reasons I sometimes put things like dates in my generated XIDs, one could have said DELETE FROM eventHandlers WHERE xid LIKE '%11-27-16%;

Sorry for the inconvenience!

[shaun]

Thanks Phil,

I'll do the upgrade out of hours and let you know the results.

Cheers!
-Shaun

[shaun]

Hi Phil,

Just did the upgrade... so far everything looks fine, but I notice all my event handlers have disappeared..

All my data sources, data points, event detectors, mailing lists, dashboards, etc are all there and working..

Tomorrow I'll have a go at re-importing my event handlers and see how it goes.

Cheers!
-Shaun

[phildunlap]

Oh no!

Can you email in the contents of your Mango/logs/Upgrade12.log and ma.log files?

[shaun]

Hi Phil,

Its not really a big deal... if thats all thats missing, and thats all I've found so far. I suspect they may have been 'cleaned up' if they were invalid configuration perhaps?

I've just emailed the logs into support@ with your name in the subject.

Cheers!
-Shaun

[shaun]

Hi Phil,

Just to update you.. I re-imported all my event handlers, and the issue from before where I couldn't edit is now gone.

Cheers!
-Shaun

[phildunlap]

Thanks!

It looks like the upgrade went fine, so I'm all the more curious how they disappeared. It says in your upgrade log: 'Upgraded 131 event handlers.' Would this have been the number of other handlers, not counting the ones we generated? Does the result from running the SQL SELECT count(id) FROM eventHandlers; give a seemingly sensible number?