Open rbeckman-nextgen opened 4 years ago
Encountered the same issue today (also on Mirth 3.5.1) but with a Sql Server backend...
Imported Comment. Original Details: Author: nicovn Created: 2018-01-24T02:46:29.000-0800
To [~jili54178] I was not able to reproduce the exact same issue. Can you please confirm if any of what i observed here ?
What is the issue: Not able to deploy channel "Generator-0001", no error in deploy but channel in
OS(s) /JREs Used: Win7 with Java Web Start 11.161.2.12 amd64 with Postgres (also reproduced with minh-vMA-test on Appliance 3.10.4)
INFO (com.mirth.connect.server.Mirth:448): Running Java HotSpot(TM) 64-Bit Server VM 1.8.0_161 on Windows 7 (6.1, amd64), postgres, with charset windows-1252.
Issue found /exists in Version(s)/Build(s): MC351.b195
Is the Issue Consistent (list details):
Channel[id=e8a15648-cbcc-4359-9c53-62a9b7841d8c,name=Generator-0002]
Steps to Reproduce:
at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:79) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:66) at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.unmarshallField(AbstractReflectionConverter.java:474) at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.doUnmarshal(AbstractReflectionConverter.java:406) at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.unmarshal(AbstractReflectionConverter.java:257) at com.thoughtworks.xstream.converters.extended.ThrowableConverter.unmarshal(ThrowableConverter.java:70) at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:72) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:66) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:50) at com.thoughtworks.xstream.core.TreeUnmarshaller.start(TreeUnmarshaller.java:134) at com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.unmarshal(AbstractTreeMarshallingStrategy.java:32) at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:1185) at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:1157) at com.mirth.connect.model.converters.ObjectXMLSerializer.deserialize(ObjectXMLSerializer.java:208) ... 40 more Caused by: com.thoughtworks.xstream.mapper.CannotResolveClassException: org.postgresql.util.PSQLException at com.thoughtworks.xstream.mapper.DefaultMapper.realClass(DefaultMapper.java:79) at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30) at com.thoughtworks.xstream.mapper.DynamicProxyMapper.realClass(DynamicProxyMapper.java:55) at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30) at com.thoughtworks.xstream.mapper.PackageAliasingMapper.realClass(PackageAliasingMapper.java:88) at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30) at com.thoughtworks.xstream.mapper.ClassAliasingMapper.realClass(ClassAliasingMapper.java:79) at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30) at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30) at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30) at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30) at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30) at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30) at com.thoughtworks.xstream.mapper.ArrayMapper.realClass(ArrayMapper.java:74) at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30) at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30) at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30) at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30) at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30) at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30) at com.thoughtworks.xstream.mapper.SecurityMapper.realClass(SecurityMapper.java:71) at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30) at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30) at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30) at com.thoughtworks.xstream.mapper.CachingMapper.realClass(CachingMapper.java:47) at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.doUnmarshal(AbstractReflectionConverter.java:401) at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.unmarshal(AbstractReflectionConverter.java:257) at com.thoughtworks.xstream.converters.extended.ThrowableConverter.unmarshal(ThrowableConverter.java:70) at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:72) ... 53 more`
Imported Comment. Original Details: Author: minht Created: 2018-04-10T16:25:59.000-0700
The reason the config Minh Tran posted caused that issue is because a channel inside the config has an incorrect ID. Right now the server expects channel IDs to be 36 characters long, but the channel in the config has an ID of "abc". So that causes issues with database queries.
But I have no idea if that's the same issue that Jason Li ran into. It doesn't sound like it.
Pushing out this issue until more concrete reproduction steps are found.
Imported Comment. Original Details: Author: narupley Created: 2018-11-19T09:16:39.000-0800
When importing configurations to Mirth Connect 3.5.1, channels become enabled but nothing happens if I try deploying a channel.
In the event logs, there is an entry for 'Deploy Channels', but when we deploy the channel it takes me to the dashboard with the channel still undeployed. Additionally, there are no entries in mirth.log indicating an error.
-------------------Steps to Reproduce-------------------
Additionally, we've run into this issue from system restarts as well. Reproducing with the configuration method above seems to require that we delete all channels and then import the configuration again.
-------------------Workaround-------------------
With the workaround, it seems that when we disable and enable the channel, the channel's entry into the channelMetadata is now present and we can deploy the channel.
A better workaround (if you have a lot of channels) is to create a group to house channels that are to be left in a disabled state. Then if you run into the issue during restarts, you can quickly disable/enable/deploy channels that are not working
Imported Issue. Original Details: Jira Issue Key: MIRTH-4230 Reporter: jili54178 Created: 2017-12-08T08:57:42.000-0800