The Field Test version of Ensemble "is not supported for the development of applications. It is for testing and evaluation purposes only", so you may want to speak to one of our Sales team people if you intend to use any installation for development.
Alexey
That cconsole.log message is a good example of the OS shutting down Cache and not necessarily gracefully, but it is NOT a definite indication of the OS killing processes that are not closing quick enough for the OS shutdown. I think if I were to see this I would then check that everything closed nicely, because it is an indication that the OS triggered the shutdown and if I don't have a long enough Timeout setting then there is a good chance that Cache processes could be killed.
In other words, not a symptom of the OS shutting down too quickly, but an indication that the OS is the cause of the shutdown and so we should check that the Cache shutdown was a good one.
I hope that answers your question.
Steve
The quick check for a good clean shutdown is to search for LCK files. Every Cache database will have an LCK file associated with it when it is mounted and these are deleted when the instance shuts down, so if there are lck files still present then this is a good indication that the shutdown was incomplete. The one exception to this is the lck file associated with the Journal files. This is not deleted at shutdown because it may be used to help/diagnose in the recovery process at next start up - you will see the file holds a path and server name.
Beyond looking for lck files and checking the cconsole.log the only other source of information (about the shutdown) is the Windows Event log.
We don't have HealthShare documentation on our central servers for public consumption, so you will have to look at your HealthShare instance documentation. From the HS symbol in your systray click and select Documentation and if that fails then it is likely that your documentation service has been disabled. If that is the case then please call our FRC or open a WRC case to have an advisor help you.
I have installed the PMD and all looks good. I would say that it has been hard to debug my own custom sensors without the ability to throw errors from the GetSensors class, but I got there.
I have found that when the user trying to look at the Poly Metric Dashboard has just the %Operator Role we get an odd problem. The graphs start displaying and then we get a browser "Login pop-up" saying that "(NULL)" has requested the login. When I look at the event trapped by the Audit log I see an illegal attempt to access a protected global...
<PROTECT>GetLanguages+15^%occMessages ^CacheMsg(""),c:\intersystems\cache162b\mgr\
...any ideas which Role or Resource I need to add to this operator?
Hi
Check your recent changes to the instance configuration by comparing the "_LastGood_.cpf" with the "cache.cpf" - both can be found in your installation directory. If you can't see an obvious difference, but there is a difference in the date-time stamp for the files then use the "_LastGood_.cpf" file to replace the "cache.cpf" file to get the instance to start.
If you have been making a lot of configuration changes recently then you may want to make a copy of the cache.cpf before trying the above.
Regards,
Steve
Hi
I would have a look at the testing service documentation here...
...this will talk you through setting up tests to look for process anomalies and bottlenecks.
Steve
I believe that PIXPDQ is "Patient Identifier Cross-Reference HL7 V3 (PIXV3) and Patient Demographic Query"
I think what you are looking at (for PIXPDQ) is any query or process that needs to check/cross-reference the MPI will use the Information Exchange Registry and the consent manager (part of the Registry) and will need to know the "User" (to get consent group info) or whether this is query/process will be using the "Consent Override" (no consent applied - "admin"?) or is an audit process, etc. I believe this is where the "Searchmode" is coming in. I think the HealthShare documentation on Information Exchange Registry will give you a better idea (obviously replace my "localhost:57774" with your own machine name and port) here is the link to the local docs...
https://www.localhost:57774/csp/docbook/DocBook.UI.Page.cls?KEY=HEOV_architecture
Hope this helps.
Just to add another possible cause; if your sql code is working on a cursor, nested query or embedded piece of sql where the sql query is complicated and takes a long time to execute then it is possible to have the underlying cursor/query timeout and this of course will give the calling code that wants to reference that inner sql nothing to work on - NULL. This too could cause the error you are seeing, but just as Michael suggested, forwarding your query/code (with nothing confidential in) would be helpful.
When the Source (not destination) is in a TCP conversation with the Shadow there are many times when the Shadow must communicate which Journal data it needs to the Source. The common times are when a Shadow starts, resumes or retries to transmit Journal data. At these times a Shadow must tell the Source things like at what point it has got up to within the Journals and what it needs next from the Source. This means that the Source will be READing (listening) from the port (TCP connection between the two), waiting for the destination to give it a start point in the Journal. Any READ will have a timeout limit, because in most Operating Systems a TCP connection will have a "KeepAlive" setting (so the connection doesn't ever timeout) and we don't want the READ to wait forever and cause the Shadow to HANG. The timeout for these Source-to-Shadow TCP Reads is 10 seconds, so if there is no response from the Source "request" to the Shadow for information then the Shadow routine is directed to record a nothing read error (as you have seen) and will then retry this part of the conversation.
In your case the destination Shadow is taking too long to send the Journal position or another piece of information that the Source needs before it transmits any Journal data. It could be that one of the processes on the destination Shadow instance is hanging or being held up, so it can't actually hand over the start point or something like it.