web stats
Could not retrieve property: category=core, name=channelDependencies - Mirth Community

Go Back   Mirth Community > Mirth Connect > Support

Thread Tools Display Modes
Old 06-10-2019, 06:13 AM
kirt kirt is offline
Mirth Newb
Join Date: Feb 2016
Location: Quebec City
Posts: 10
kirt is on a distinguished road
Default Could not retrieve property: category=core, name=channelDependencies

This issue is related to a previous post: http://www.mirthproject.org/communit...d.php?p=257018

I am running Mirth at a high volume site. I am encountering the same issue - see quote at bottom.

The previous post indicates I could simply delete the constantly inserted records using:
DELETE FROM configuration WHERE category = 'core' AND name = 'channelDependencies';
These brings up a few follow-up questions:

i. Are there any risks to active channels to doing this?
ii. Should I first stop inbound traffic permit any queues to empty out?
iii. What's to stop these unexpected entries to continue being added?

[2019-06-10 09:05:20,668] WARN (com.mirth.connect.server.controllers.DefaultConfi gurationController:839): Could not retrieve property: category=core, name=channelDependencies
org.apache.ibatis.exceptions.TooManyResultsExcepti on: Expected one result (or null) to be returned by selectOne(), but found: 2482563
at org.apache.ibatis.session.defaults.DefaultSqlSessi on.selectOne(DefaultSqlSession.java:63)
at sun.reflect.GeneratedMethodAccessor37.invoke(Unkno wn Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Un known Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.ibatis.session.SqlSessionManager$SqlSes sionInterceptor.invoke(SqlSessionManager.java:282)
at com.sun.proxy.$Proxy6.selectOne(Unknown Source)
at org.apache.ibatis.session.SqlSessionManager.select One(SqlSessionManager.java:151)
at com.mirth.connect.server.controllers.DefaultConfig urationController.getProperty(DefaultConfiguration Controller.java:837)
at com.mirth.connect.server.controllers.DefaultConfig urationController.saveProperty(DefaultConfiguratio nController.java:855)
at com.mirth.connect.server.controllers.DefaultConfig urationController.setChannelDependencies(DefaultCo nfigurationController.java:934)
at com.mirth.connect.server.controllers.DefaultConfig urationController.getChannelDependencies(DefaultCo nfigurationController.java:919)
at com.mirth.connect.server.api.servlets.Configuratio nServlet.getChannelDependencies(ConfigurationServl et.java:332)
at sun.reflect.GeneratedMethodAccessor84.invoke(Unkno wn Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Un known Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.mirth.connect.server.api.providers.MirthResour ceInvocationHandlerProvider$1.invoke(MirthResource InvocationHandlerProvider.java:211)
at org.glassfish.jersey.server.model.internal.Abstrac tJavaResourceMethodDispatcher$1.run(AbstractJavaRe sourceMethodDispatcher.java:144)
at org.glassfish.jersey.server.model.internal.Abstrac tJavaResourceMethodDispatcher.invoke(AbstractJavaR esourceMethodDispatcher.java:161)
at org.glassfish.jersey.server.model.internal.JavaRes ourceMethodDispatcherProvider$TypeOutInvoker.doDis patch(JavaResourceMethodDispatcherProvider.java:20 5)
at org.glassfish.jersey.server.model.internal.Abstrac tJavaResourceMethodDispatcher.dispatch(AbstractJav aResourceMethodDispatcher.java:99)
at org.glassfish.jersey.server.model.ResourceMethodIn voker.invoke(ResourceMethodInvoker.java:389)
at org.glassfish.jersey.server.model.ResourceMethodIn voker.apply(ResourceMethodInvoker.java:347)
at org.glassfish.jersey.server.model.ResourceMethodIn voker.apply(ResourceMethodInvoker.java:102)
at org.glassfish.jersey.server.ServerRuntime$2.run(Se rverRuntime.java:326)
at org.glassfish.jersey.internal.Errors$1.call(Errors .java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors .java:267)
at org.glassfish.jersey.internal.Errors.process(Error s.java:315)
at org.glassfish.jersey.internal.Errors.process(Error s.java:297)
at org.glassfish.jersey.internal.Errors.process(Error s.java:267)
at org.glassfish.jersey.process.internal.RequestScope .runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process( ServerRuntime.java:305)
at org.glassfish.jersey.server.ApplicationHandler.han dle(ApplicationHandler.java:1154)
at org.glassfish.jersey.servlet.WebComponent.serviceI mpl(WebComponent.java:471)
at org.glassfish.jersey.servlet.WebComponent.service( WebComponent.java:425)
at org.glassfish.jersey.servlet.ServletContainer.serv ice(ServletContainer.java:383)
at org.glassfish.jersey.servlet.ServletContainer.serv ice(ServletContainer.java:336)
at org.glassfish.jersey.servlet.ServletContainer.serv ice(ServletContainer.java:223)
at org.eclipse.jetty.servlet.ServletHolder.handle(Ser vletHolder.java:812)
at org.eclipse.jetty.servlet.ServletHandler$CachedCha in.doFilter(ServletHandler.java:1669)
at com.mirth.connect.server.MethodFilter.doFilter(Met hodFilter.java:37)
at org.eclipse.jetty.servlet.ServletHandler$CachedCha in.doFilter(ServletHandler.java:1652)
at com.mirth.connect.server.api.providers.ApiOriginFi lter.doFilter(ApiOriginFilter.java:35)
at org.eclipse.jetty.servlet.ServletHandler$CachedCha in.doFilter(ServletHandler.java:1652)
at org.eclipse.jetty.servlet.ServletHandler.doHandle( ServletHandler.java:585)
at org.eclipse.jetty.server.session.SessionHandler.do Handle(SessionHandler.java:221)
at org.eclipse.jetty.server.handler.ContextHandler.do Handle(ContextHandler.java:1127)
at org.eclipse.jetty.servlet.ServletHandler.doScope(S ervletHandler.java:515)
at org.eclipse.jetty.server.session.SessionHandler.do Scope(SessionHandler.java:185)
at org.eclipse.jetty.server.handler.ContextHandler.do Scope(ContextHandler.java:1061)
at org.eclipse.jetty.server.handler.ScopedHandler.han dle(ScopedHandler.java:141)
at org.eclipse.jetty.server.handler.HandlerList.handl e(HandlerList.java:52)
at org.eclipse.jetty.server.handler.HandlerWrapper.ha ndle(HandlerWrapper.java:97)
at org.eclipse.jetty.server.Server.handle(Server.java :499)
at org.eclipse.jetty.server.HttpChannel.handle(HttpCh annel.java:311)
at org.eclipse.jetty.server.HttpConnection.onFillable (HttpConnection.java:257)
at org.eclipse.jetty.io.AbstractConnection$2.run(Abst ractConnection.java:544)
at org.eclipse.jetty.util.thread.QueuedThreadPool.run Job(QueuedThreadPool.java:635)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.r un(QueuedThreadPool.java:555)
at java.lang.Thread.run(Unknown Source)
Reply With Quote
Old 06-12-2019, 09:09 AM
kirt kirt is offline
Mirth Newb
Join Date: Feb 2016
Location: Quebec City
Posts: 10
kirt is on a distinguished road
Default Removed only Duplicates to remedy

I find that just outright deleting all culprit records from the CONFIGURATION table a bit nerve racking. Here's what I did to ease my mind.

The following are commands for mirthdb running on SQL Server.

First, one can easily recreate the issue in a test environment by adding a duplicate record into a test env.
INSERT INTO Configuration(CATEGORY, NAME, VALUE) VALUES(N'core', N'channelDependencies', N'<set/>');
Once you run this, you'll see the number of records in the Configuration table increases by one every few seconds. Similarly, with the appropriate logging you see all the warnings on the Administrator server output.

Rather than remove all the 'channelDependencies' records leaving none behind (see included link in original post). I was much more at ease removing all but one. Once you do this, the warning goes away and no more duplicate records keep getting added. I verified this in a test environment first before repeating the same steps in production.

For mirthdb running on SQL Server the command to remove duplicate records looks like:
WITH TargetTable AS
ROW_NUMBER() over (ORDER BY CATEGORY) ROWID, Category, name, value
where name = 'channelDependencies')
The where clause in above SQL command is based on the assumption that there was just one channelDependencies record before the problem emerged. I confirmed this in my case by comparing test with production entries in this CONFIGURATION table.

One can perform this knowing that if the Mirth service is looking-for or dependent-on on this configuration record, you've left a least one record in place for it.

I performed this work without any interruption to the Mirth server/service.

Last edited by kirt; 06-12-2019 at 09:18 AM. Reason: spelling mistakes, rephrasing
Reply With Quote
Old 06-12-2019, 12:06 PM
agermano agermano is offline
Mirth Guru
Join Date: Apr 2017
Location: Indiana, USA
Posts: 894
agermano is on a distinguished road

Were all of the values the same? Did you ever set up any channel dependencies to begin with? I would expect that if it had trouble reading the property that it would default to an empty set, which it would then try to store back to the db.

I would guess that deleting all of them would have the same effect as deleting all but one empty set. Deleting all but one could be useful if you ever used channel dependencies in the past, and the record you keep isn't an empty set.

Perhaps the table should have a unique constraint on (category,name) to prevent this from happening.
Reply With Quote
Old 06-13-2019, 06:57 AM
kirt kirt is offline
Mirth Newb
Join Date: Feb 2016
Location: Quebec City
Posts: 10
kirt is on a distinguished road
Default new versions have a primary key, not sure about unique constraint

The values were all the same "<set/>".

Under channel properties, I do have dependencies configured for a couple of Code Template Libraries. Hence, I was a bit perplexed why the set was empty. Perhaps, it is another type of dependency.

My objective in deleting all but one was to mitigate any risk. I felt the the cost of a more intricate SQL statement was well worth it.

I understand that new versions of Mirth indeed have a unique key in this table. That would make the delete job easier. However, I think the logic would further benefit from a constraint that insures that multiple rows with the same values for category, name and value cannot be added to the configuration table.
Reply With Quote
Old 06-13-2019, 09:05 AM
agermano agermano is offline
Mirth Guru
Join Date: Apr 2017
Location: Indiana, USA
Posts: 894
agermano is on a distinguished road

The channelDependies in that setting are when one channel depends on another channel. You can create those to ensure correct deploy order, and it will prompt you when redeploying when there are channel dependencies.

It looks like as of mirth 3.5 there is a primary key constraint over (category, name)
Reply With Quote
Old 06-13-2019, 09:13 AM
kirt kirt is offline
Mirth Newb
Join Date: Feb 2016
Location: Quebec City
Posts: 10
kirt is on a distinguished road

Thanks for the insight.

deployAndStartChannelDependencies would be more intuitive and precise name than channelDependencies
Reply With Quote

warning configuration

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

All times are GMT -8. The time now is 04:24 AM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.
Mirth Corporation