search

osullivj / pymqi

Python interface to WebSphere MQ (MQSeries) - main docs at https://pythonhosted.org/pymqi/index.html
Other
0 stars 0 forks source link

pymqe compile flags #2

Open osullivj opened 6 years ago

osullivj commented 6 years ago

Is there a threading problem with these compile flags?

[ec2-user@ip-172-31-33-194 code]$ python setup.py build Building PyMQI client 64bits running build running build_py running build_ext building 'pymqi.pymqe' extension gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -DPYQMI_SERVERBUILD=0 -I/opt/mqm/inc -I/usr/include/python2.7 -c pymqi/pymqe.c -o build/temp.linux-x86_64-2.7/pymqi/pymqe.o gcc -pthread -shared build/temp.linux-x86_64-2.7/pymqi/pymqe.o -L/opt/mqm/lib64 -L/usr/lib64 -lmqic_r -lpython2.7 -o build/lib.linux-x86_64-2.7/pymqi/pymqe.so [ec2-user@ip-172-31-33-194 code]$

osullivj commented 6 years ago

https://stackoverflow.com/questions/2127797/significance-of-pthread-flag-when-compiling

osullivj commented 6 years ago

http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/i386-and-x86_002d64-Options.html mtune: tune to specific CPU - 386, 486, AMD etc pthread: set _REENTRANT, and link libpthread eg -lpthread on link line no-strict-aliasing: ptr optimisations pipe: use pipes not temp files for comms between gcc stages

osullivj commented 6 years ago

setup.py GCC flags are inherited from the flags to build Python itself! https://stackoverflow.com/questions/6928110/how-may-i-override-the-compiler-gcc-flags-that-setup-py-uses-by-default https://docs.python.org/2.5/inst/tweak-flags.html https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html https://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/Preprocessor-Options.html

-Wall: all warnings -Wp,-d_FORTIFY_SOURCE: bypass compiler driver, _FORTIFY_SOURCE (buf over) direct to preproc stuff -fexceptions: exception handling codegen -fstack-protector: stack buf chks --param=ssp-buffer-size=4: stack protector tweak -m64: Nvidia GPU flag -fPic: position independent code -fwrapv: signed arithmetic in wrapping

osullivj commented 6 years ago

-DPYQMI_SERVERBUILD=0: see pymqe.c. Build for MQ client, not server.

osullivj commented 6 years ago

We should use MQCNO_HANDLE_SHARE_BLOCK to ensure that multiple threads can GET/PUT simultaneously with the same connection handle from different threads. http://mqseries.net/phpBB/viewtopic.php?t=35343&sid=07f321a891ff910f8015f1ec12a503c2

osullivj commented 6 years ago

https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.5.0/com.ibm.mq.tro.doc/q040860_.htm "An MQCONNX call was issued specifying the option MQCNO_HANDLE_SHARE_NONE on an MQ channel exit, an API Exit, or a Callback function. The reason code occurs only if a shared hConn is bound to the application thread." Is our canned API exit calling MQCONNX?

osullivj commented 6 years ago

http://www.mqseries.net/phpBB/viewtopic.php?t=16203&sid=1aba0abbac445f7bb630dd3c1bc5f4de Solved: Called IBM. I needed to export the following env. vars in the shell script: export LD_ASSUME_KERNEL=2.4.19 export AMQ_THREADMODEL_RESET=1 export AMQ_INHIBIT_DLCLOSE=TRUE

osullivj commented 6 years ago

http://mqseries.net/phpBB/viewtopic.php?p=333007&sid=6d6360a7f3255a7f21e244463c07c070 Check we're using _r.so libs all the way for thread safety.

osullivj commented 6 years ago

http://ibm.software.websphere.mq.programming.narkive.com/wCHUv23r/can-t-solve-error-2012-problem-on-linux-2-4-21-4 Before running your app, try export LD_ASSUME_KERNEL=2.4.19 MQ 5.3 uses the old LinuxThreads model, whereas your kernel uses the new LNTP model.

osullivj commented 6 years ago

http://www.mqseries.net/phpBB/viewtopic.php?p=173070&sid=29730384ad0328fdd377f09313655350 Linux kernel 2.4 doesn't support posix threads natively, 2.6+ does.

osullivj commented 6 years ago

https://www.mail-archive.com/mqseries@akh-wien.ac.at/msg16282.html AMQ_THREADMODEL_RESET just sets LD_ASSUME_KERNEL=2.4.19, but only for MQAPI, not for other procs.

osullivj commented 6 years ago

Possible fixes to 2012 issue... Check the linux exit: does it call MQCONNX? Check kernel version: is it 2.4 or 2.6? Change Python code to do all MQ ops on the same thread. Change Python code to retry the connection when we get a 2012. run nm on the MQAPI exit .so Check py uses MQCNO_HANDLE_SHARE_BLOCK

osullivj commented 6 years ago

Exit does not call MQCONNX; it just does auth. Linux kernel is 3.10.0-693.11.1.el7.x86_64.