New post

Find

Question
· Nov 15, 2024

Base 64 message is taking considering as a new segment

Hi Team,

I am converting xml message into HL7 message but the input XML message contains pdf which is converting into base 64 and getting mapped to OBX:5.5 in HL7 message and sending it to downstream 

In Downstream service i am using normal HL7 TCP class EnsLib.HL7.Service.TCPService but the message looks like below i am not sure why stream is taking as another segment in HL7 message,

Any thoughts on this?

 

Thanks,

Smythee

15 Comments
Discussion (15)3
Log in or sign up to continue
Announcement
· Nov 15, 2024

IA de la Comunidad de Desarrolladores: Se ha añadido documentación de InterSystems IRIS

Hola Comunidad,

¡Estamos emocionados de anunciar una nueva mejora en la IA de la Comunidad de Desarrolladores!

Ahora, además de los posts y comentarios de la Comunidad, la IA de la Comunidad de Desarrolladores también extrae información de la documentación oficial de InterSystems IRIS para responder a vuestras preguntas. Esta nueva función os permite personalizar las fuentes de búsqueda para obtener las respuestas más relevantes y adaptadas a vuestras necesidades.

Simplemente elegid las fuentes y formulad la pregunta:

  • Publicaciones de la comunidad
  • Documentación de InterSystems IRIS
  • ¡o ambas!

Con la documentación ahora añadida a la base de conocimiento, sentíos libres de hacer vuestras preguntas de nuevo: es posible que recibáis una respuesta diferente y más precisa.  

¡Echadle un vistazo y compartid vuestra opinión en los comentarios!

Discussion (0)1
Log in or sign up to continue
Question
· Nov 15, 2024

Illegal instruction (core dumped) for "iris-community:2024.1"

Hello. On some hosts, IRIS in containers.intersystems.com/intersystems/iris-community:2024.1 falls with a core dump.

auser:~$ docker run --rm -it --entrypoint=""  containers.intersystems.com/intersystems/iris-community:2024.1 bash
irisowner@6170dcdbe77c:~$ iris start IRIS
Illegal instruction (core dumped)

Coredump stack:

(gdb) bt
#0  0x000055688cf44743 in osregopen ()
#1  0x000055688cf4060a in ListConfig ()
#2  0x000055688cf3dcd7 in main ()

Are there some hardware requirements for IRIS docker container? Or maybe some specific settings?

Host details:
 

auser:~$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 26
model name      : Intel Core i7 9xx (Nehalem Class Core i7)
stepping        : 3
microcode       : 0x1
cpu MHz         : 2095.076
cache size      : 16384 KB
physical id     : 0
siblings        : 1
core id         : 0
cpu cores       : 1
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx lm constant_tsc rep_good nopl xtopology cpuid t
sc_known_freq pni ssse3 cx16 sse4_1 sse4_2 x2apic popcnt hypervisor lahf_lm cpuid_fault pti
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit mmio_unknown bhi
bogomips        : 4190.15
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:
...

processor       : 9
...


 

aueser:~$ cat /proc/meminfo
MemTotal:       16371580 kB
MemFree:          636500 kB
MemAvailable:   15507536 kB
Buffers:          359200 kB
Cached:         14237744 kB
SwapCached:            0 kB
Active:          4010196 kB
Inactive:       10817652 kB
Active(anon):       1356 kB
Inactive(anon):   244032 kB
Active(file):    4008840 kB
Inactive(file): 10573620 kB
Unevictable:       31752 kB
Mlocked:           27752 kB
SwapTotal:       4194300 kB
SwapFree:        4194300 kB
Dirty:                60 kB
Writeback:             0 kB
AnonPages:        262520 kB
Mapped:           255232 kB
Shmem:              5420 kB
KReclaimable:     630116 kB
Slab:             768684 kB
SReclaimable:     630116 kB
SUnreclaim:       138568 kB
KernelStack:        5632 kB
PageTables:         5400 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    12380088 kB
Committed_AS:    1516592 kB
VmallocTotal:   34359738367 kB
VmallocUsed:       26172 kB
VmallocChunk:          0 kB
Percpu:            10800 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
ShmemPmdMapped:        0 kB
FileHugePages:         0 kB
FilePmdMapped:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:               0 kB
DirectMap4k:      278380 kB
DirectMap2M:    16498688 kB

OS data:

auser:~$ cat /etc/os-release 
PRETTY_NAME="Ubuntu 22.04.5 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.5 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy

 

2 Comments
Discussion (2)2
Log in or sign up to continue
Question
· Nov 15, 2024

stream.Read() only reading in chunks of 1K

I use the following code to calculate the SHA1 of a file :

set stream = ##class(%Stream.FileBinary).%New()
do stream.LinkToFile(filename)
write $SYSTEM.Encryption.Base64Encode($SYSTEM.Encryption.SHA1HashStream(stream))

This code is called thousands of time and performance is critical. I have tried to code same logic in another language (which is lower level) and it's almost twice as fast. It's unclear why so I started investigating.

Using Process Monitor, it shows that files are read in chunks of 1024 bytes (1K) which is suboptimal. Reading a file of 1MB while require 1024 file system calls. Usually bigger buffer is used (eg : 4096 or 81920).

The SHA1HashStream() function is implemented this way : 

do $System.Encryption.SHAHashReset(160)
set sc=stream.Rewind() If $$$ISERR(sc) Quit ""
while 'stream.AtEnd {
	do $System.Encryption.SHAHashInput(160, stream.Read(32000,.sc))
	if $$$ISERR(sc) Quit
}
quit $System.Encryption.SHAHashResult(160)

stream.Read(32000) will do the following call :

Read:32000

So I except it to read the file in chunks of 32000 bytes, but that's not the case.

Is this excepted behavior ? Is there a way to change this ?

EDIT: I have been able to force 1024 bytes reads in the other language implementation and it's still about twice faster so performance issue is probably due to something else.

2 Comments
Discussion (2)1
Log in or sign up to continue
Article
· Nov 14, 2024 2m read

第二十一章 TCP 客户端 服务器通信 - 客户端OPEN命令

第二十一章 TCP 客户端 服务器通信 - 客户端OPEN命令

客户端OPEN命令

客户端OPEN命令与服务器端OPEN命令只有一个方面的不同:第一个设备参数必须指定要连接的主机。要指定主机,需要包括客户端识别为主机的名称或Internet地址。

一旦建立连接,OPEN开就会成功。此时,可以读取或写入该TCP设备。但是,如果连接的服务器端是另一个IRIS进程,则在使用WRITE命令将一些数据从客户端发送到服务器之前,服务器不会完成其连接端。因此,必须在发出任何读取命令之前发出写入命令。

客户端 OPEN 命令的一些示例是:

Discussion (0)1
Log in or sign up to continue