go to post Eduard Lebedyuk · Aug 10, 2022 This is a limitation on a maximum resource length that was lifted in 2022.2 preview 4.
go to post Eduard Lebedyuk · Aug 10, 2022 I would start by observing the output of these two commands when run from a Dockerfile: set sc = ##class(Ens.Director).SetAutoStart("GOJ.IrisApp.ProductionDev") write $system.Status.GetErrorText(sc) set sc = ##class(Ens.Director).StartProduction("GOJ.IrisApp.ProductionDev") write $system.Status.GetErrorText(sc)
go to post Eduard Lebedyuk · Aug 9, 2022 HS.SDA3.Container is a registered object and not a persistent one, so you can't pass it directly. What you can do, however, is to pass existing stream id in your request, this way stream is not copied twice (you only pass an id) and receiver then can recreate the same HS.SDA3.Container from a stream.
go to post Eduard Lebedyuk · Aug 4, 2022 For this type of data, you can make your own indexes for different parts and/or combinations of them: a separate date, a separate time, a separate year, a separate year and month, etc. Could you elaborate on that, please?
go to post Eduard Lebedyuk · Aug 3, 2022 That's a different connection (connection to remote gateway server), rather that a license/csp connection. Check that %Java Server External Language Server can start. In your case it does not start. We wait for 60 seconds because it can take a while for External Language Server to start - it can be on another server for example. Calling @Benjamin De Boe.
go to post Eduard Lebedyuk · Aug 3, 2022 Even easier with DATEDIFF: set age = $SYSTEM.SQL.Functions.DATEDIFF("year", dob, $h)
go to post Eduard Lebedyuk · Aug 2, 2022 Yes? Cubes need space to store thier copy of the facts and CPU is needed to build it all. As I said above, using async reporting mirror for cubes would completely remove the impact on the patient index.
go to post Eduard Lebedyuk · Jul 28, 2022 Great article. Here's some of my ideas on how to pass large strings/streams to InterSystems IRIS from Native API.
go to post Eduard Lebedyuk · Jul 25, 2022 Yeah, the process had 64,5 Gb of virtual memory allocated and 40Gb actually used. Not surprised OOM killed that.
go to post Eduard Lebedyuk · Jul 25, 2022 That's InterSystems IRIS logs. You need OS logs, namely syslog (check /var/log/syslog or /var/log/messages). Search for log entries about the "killed process" around the time your process was killed. To be extra sure run write $job before calling the query to get process id. It should match the id of a killed process. After you establish that your process was killed by OOM you need to report that to WRC, as a fix probably requires if not access, then at least overview of the production configuration which causes it.
