You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafodion.apache.org by "Song, Hao-Lin" <ha...@esgyn.cn> on 2018/03/27 15:19:35 UTC
Question about Trafodion MXOSRVR
Hi all
I found that mxosrvr could not handle other network messages when a query is processing , since network processing and data processing are in the same thread. I am confused about this. Can we put them in different threads to make the program more clear and potential?
Best,
Haolin
RE: Question about Trafodion MXOSRVR
Posted by Selva Govindarajan <se...@esgyn.com>.
What are the other network messages that need to be acted upon by mxosrvr? ODBC/JDBC APIs are blocking. Other than cancelling query, there should no other messages from the driver sent to the server at least on behalf of the application. The messages between mxosrvr and the ESPs are encapsulated in Trafodion's own IPC mechanism. I believe mxosrvr is capable of alternatively listening between the IPC messages and the messages from the driver via TCP/IP.
Are you planning to make mxosrvr multi-threaded or just want to way to process the any other message when mxosrvr is stuck processing the query.
Selva
-----Original Message-----
From: Dave Birdsall <da...@esgyn.com>
Sent: Tuesday, March 27, 2018 8:26 AM
To: dev@trafodion.apache.org
Subject: RE: Question about Trafodion MXOSRVR
Hi,
This is an accident of history. The predecessor product was developed on a platform that did not support operator multi-threading.
Yes, it is certainly possible to rearchitect mxosrvr to make it multi-threaded. This can be tricky and must be done carefully. One must take into account any global variables the code uses and decide whether to leave them as globals (and co-ordinate access with mutex), make them thread-globals, or refactor them into some object that is not a global instead.
Dave
-----Original Message-----
From: Song, Hao-Lin <ha...@esgyn.cn>
Sent: Tuesday, March 27, 2018 8:20 AM
To: dev@trafodion.apache.org
Subject: Question about Trafodion MXOSRVR
Hi all
I found that mxosrvr could not handle other network messages when a query is processing , since network processing and data processing are in the same thread. I am confused about this. Can we put them in different threads to make the program more clear and potential?
Best,
Haolin
RE: Question about Trafodion MXOSRVR
Posted by Selva Govindarajan <se...@esgyn.com>.
Please refer to my earlier response. AWAITOX and other APIs used for communication that are not TCP/IP APIs belong to the IPC( Inter process communication messages) between MXOSRVR and ESPs (Executor Server Processes) and clustering infrastructure used in Trafodion.
Selva
-----Original Message-----
From: Song, Hao-Lin <ha...@esgyn.cn>
Sent: Tuesday, March 27, 2018 9:21 AM
To: dev@trafodion.apache.org
Subject: 答复: Question about Trafodion MXOSRVR
Hi
Thanks for your explanation.
In Listener_srvr_ps.cpp, it starts a thread to do tcpip listener and handle messages and tasks. I mean that could we simply separate network processing from task processing instead of converting it to completely multi-threads . Besides, does anyone know the role of the API AWAITIOX and related ones?
I could not search it on the Internet and I don't know what is the 'while (m_bKeepRunning) ' mean?.
511
512
// Start tcpip listener thread
513
tcpip_tid = tcpip_listener_thr.create("TCPIP_listener",
514
CNSKListenerSrvr::tcpip_listener, this);
515
516
// Persistently wait for input on $RECEIVE and then act on it.
517
while(m_bKeepRunning)
518
{
519
RESET_ERRORS((long)0);
520
521
timeout = -1;
522
fnum = m_ReceiveFnum;
523
524
cc = AWAITIOX(&fnum, OMITREF, &countRead, &tag, timeout);
________________________________
发件人: Dave Birdsall <da...@esgyn.com>
发送时间: 2018年3月27日 23:26:03
收件人: dev@trafodion.apache.org
主题: RE: Question about Trafodion MXOSRVR
Hi,
This is an accident of history. The predecessor product was developed on a platform that did not support operator multi-threading.
Yes, it is certainly possible to rearchitect mxosrvr to make it multi-threaded. This can be tricky and must be done carefully. One must take into account any global variables the code uses and decide whether to leave them as globals (and co-ordinate access with mutex), make them thread-globals, or refactor them into some object that is not a global instead.
Dave
-----Original Message-----
From: Song, Hao-Lin <ha...@esgyn.cn>
Sent: Tuesday, March 27, 2018 8:20 AM
To: dev@trafodion.apache.org
Subject: Question about Trafodion MXOSRVR
Hi all
I found that mxosrvr could not handle other network messages when a query is processing , since network processing and data processing are in the same thread. I am confused about this. Can we put them in different threads to make the program more clear and potential?
Best,
Haolin
答复: Question about Trafodion MXOSRVR
Posted by "Song, Hao-Lin" <ha...@esgyn.cn>.
Hi
Thanks for your explanation.
In Listener_srvr_ps.cpp, it starts a thread to do tcpip listener and handle messages and tasks. I mean that could we simply separate network processing from task processing instead of converting it to completely multi-threads . Besides, does anyone know the role of the API AWAITIOX and related ones?
I could not search it on the Internet and I don't know what is the 'while (m_bKeepRunning) ' mean?.
511
512
// Start tcpip listener thread
513
tcpip_tid = tcpip_listener_thr.create("TCPIP_listener",
514
CNSKListenerSrvr::tcpip_listener, this);
515
516
// Persistently wait for input on $RECEIVE and then act on it.
517
while(m_bKeepRunning)
518
{
519
RESET_ERRORS((long)0);
520
521
timeout = -1;
522
fnum = m_ReceiveFnum;
523
524
cc = AWAITIOX(&fnum, OMITREF, &countRead, &tag, timeout);
________________________________
发件人: Dave Birdsall <da...@esgyn.com>
发送时间: 2018年3月27日 23:26:03
收件人: dev@trafodion.apache.org
主题: RE: Question about Trafodion MXOSRVR
Hi,
This is an accident of history. The predecessor product was developed on a platform that did not support operator multi-threading.
Yes, it is certainly possible to rearchitect mxosrvr to make it multi-threaded. This can be tricky and must be done carefully. One must take into account any global variables the code uses and decide whether to leave them as globals (and co-ordinate access with mutex), make them thread-globals, or refactor them into some object that is not a global instead.
Dave
-----Original Message-----
From: Song, Hao-Lin <ha...@esgyn.cn>
Sent: Tuesday, March 27, 2018 8:20 AM
To: dev@trafodion.apache.org
Subject: Question about Trafodion MXOSRVR
Hi all
I found that mxosrvr could not handle other network messages when a query is processing , since network processing and data processing are in the same thread. I am confused about this. Can we put them in different threads to make the program more clear and potential?
Best,
Haolin
RE: Question about Trafodion MXOSRVR
Posted by Dave Birdsall <da...@esgyn.com>.
Hi,
This is an accident of history. The predecessor product was developed on a platform that did not support operator multi-threading.
Yes, it is certainly possible to rearchitect mxosrvr to make it multi-threaded. This can be tricky and must be done carefully. One must take into account any global variables the code uses and decide whether to leave them as globals (and co-ordinate access with mutex), make them thread-globals, or refactor them into some object that is not a global instead.
Dave
-----Original Message-----
From: Song, Hao-Lin <ha...@esgyn.cn>
Sent: Tuesday, March 27, 2018 8:20 AM
To: dev@trafodion.apache.org
Subject: Question about Trafodion MXOSRVR
Hi all
I found that mxosrvr could not handle other network messages when a query is processing , since network processing and data processing are in the same thread. I am confused about this. Can we put them in different threads to make the program more clear and potential?
Best,
Haolin