I use both Windows 10 and Debian Jessie and both provide similar results. I've also done mixed testing HS in Linux and the plugin on Windows 7.
mcsMQTT is very multithreaded. I see no indication that the plugin has any delay in responding the HS. The transaction that has issue is
User hits show button
HS postback the button hit to plugin
...Plugin responds with 'Please Wait' text in DivToUpdate API call
...Plugin spawn thread to build Association table
...Plugin returns from HS postback
HS posts 2 second timer event
...Plugin refreshes table size status where button was pressed
...Plugin returns
HS posts 2 second timer event
...Plugin responds with DivToUpdate with HTML for Association table generated in other thread
...Plugin returns
Two seconds later no timer postback from HS
Lack of postback continues for 10 seconds, 20 seconds etc
HS posts 2 second timer event (The browser now has table rendered)
...Plugin responds with DivToUpdate to restore the Show button
...Plugin returns
If the table is too large then the 2 second postback will never occur
I do not have socket disconnects between HS and the plugin, but your data shows that the socket connection status goes to disconnected in main loop that is being monitored by the plugin at 10 millisecond intervals.
It looks to me as if HS got caught up in managing the HTML server and was unable to satisfy the criteria for keeping the main connection alive. I, however, have no visibility on what criteria exists to keep the connection alive. From the plugin side there is no management of the connection and its job is just to sense that the connection is lost, shut itself down so HS can then start it up again at its next monitoring interval.
Something like wireshark could see what is happening at the TCP/IP level with the socket. Since I cannot create the main loop disconnect problem there is nothing for me to look at with Wireshark.
Prior to 3.2.6.0 the transaction with the Show button was to remain in the same thread as called with the button push postback and not return until the table was constructed. There was no DivToUpdate calls made to change the text/button to provide progress feedback. This means that the CPU was dedicated to building the table during this time and the return back to HS would be a second or two rather than the milliseconds it is taking with the newer design. What it did do is added some additional burden for HS Server to communicate the progress status to the Browser at each of what turned out to be two updates.
When comparing to other plugins behavior the question that needs to asked is to what degree are these other plugins asking the HS server to build tables of HTML the size that mcsMQTT is asking? The issues now are not with general plugin operation, but in Web Page update. I suspect that all your other plugins have very modest demands on the HS Server. If this is not the case then perhaps a dialog can be opened with the author of one that produces large tables of HTML that can be dynamically updated.
mcsMQTT is very multithreaded. I see no indication that the plugin has any delay in responding the HS. The transaction that has issue is
User hits show button
HS postback the button hit to plugin
...Plugin responds with 'Please Wait' text in DivToUpdate API call
...Plugin spawn thread to build Association table
...Plugin returns from HS postback
HS posts 2 second timer event
...Plugin refreshes table size status where button was pressed
...Plugin returns
HS posts 2 second timer event
...Plugin responds with DivToUpdate with HTML for Association table generated in other thread
...Plugin returns
Two seconds later no timer postback from HS
Lack of postback continues for 10 seconds, 20 seconds etc
HS posts 2 second timer event (The browser now has table rendered)
...Plugin responds with DivToUpdate to restore the Show button
...Plugin returns
If the table is too large then the 2 second postback will never occur
I do not have socket disconnects between HS and the plugin, but your data shows that the socket connection status goes to disconnected in main loop that is being monitored by the plugin at 10 millisecond intervals.
It looks to me as if HS got caught up in managing the HTML server and was unable to satisfy the criteria for keeping the main connection alive. I, however, have no visibility on what criteria exists to keep the connection alive. From the plugin side there is no management of the connection and its job is just to sense that the connection is lost, shut itself down so HS can then start it up again at its next monitoring interval.
Something like wireshark could see what is happening at the TCP/IP level with the socket. Since I cannot create the main loop disconnect problem there is nothing for me to look at with Wireshark.
Prior to 3.2.6.0 the transaction with the Show button was to remain in the same thread as called with the button push postback and not return until the table was constructed. There was no DivToUpdate calls made to change the text/button to provide progress feedback. This means that the CPU was dedicated to building the table during this time and the return back to HS would be a second or two rather than the milliseconds it is taking with the newer design. What it did do is added some additional burden for HS Server to communicate the progress status to the Browser at each of what turned out to be two updates.
When comparing to other plugins behavior the question that needs to asked is to what degree are these other plugins asking the HS server to build tables of HTML the size that mcsMQTT is asking? The issues now are not with general plugin operation, but in Web Page update. I suspect that all your other plugins have very modest demands on the HS Server. If this is not the case then perhaps a dialog can be opened with the author of one that produces large tables of HTML that can be dynamically updated.
Comment