So I installed v2.2 (business edition) on vBulletin 4.2 that's running on a CentOS equipped dedicated server. I am currently not subscribed for the push service.
I've been testing my installation over the past two days. I'll first say that, for the most part, ArrowChat seems to work wonderfully. But there seem to be a couple of exceptions. In this post I'll focus on the one I consider the most serious.
During my testing I have been finding that -for me at least- sending instant private messages to any Android device, from either another mobile device or a desktop computer, results in a significant number of those sent messages randomly failing to arrive on the destination Android device's mobile ArrowChat interface session. If I send numbers 1 through 10 to the device, for example, a majority of the time one or two messages will not come through to its ArrowChat session. Well, I should clarify that a bit. The messages will actually come through if I refresh the mobile browser session. And this suggests to me that all of the sent messages are posting to the mysql database but for some reason not making it through to the destination device's real-time chat session.
A few things to add here. All messages sent to the Android mobile device during chatroom conversations come through immediately. And that is 100% of them every time - no browser refreshing is thus necessary for chatroom conversations. Also, all instant private messages sent from an Android device seem to consistently come through on any desktop computer. Just not the other way around. Then, of course, desktop computer to desktop computer instant private chat always seems to come through flawlessly.
So what gives? Is there something not quite right with ArrowChat's mobile interface for Android? Or is something not configured right on my server? I did find a few other threads in this forum's history where folks were experiencing the same or similar issues. But there didn't seem to be an indication within those threads that any of the OP's resolved their respective issue... or if any of them did, what was determined as causation.
My questions:
1) Is there a way to resolve this matter?
2) Is anyone other than myself experiencing it?
Thanks
-
zoxtrix - Customer
- Posts: 74
- Joined: 29 Jun 2019, 19:31
-
zoxtrix - Customer
- Posts: 74
- Joined: 29 Jun 2019, 19:31
Happy 4th, all!
I've decided to better outline some of the factors relevant to this problem and the various testing I've done. The issue does not appear to be server-load related. It instead appears to be Android related with an extra unknown factor (possibly involving the hosting server - but I'm unsure). Below is a list of particulars I have confirmed through reproducible results.
ArrowChat private message delivery failure particulars:
Thanks
I've decided to better outline some of the factors relevant to this problem and the various testing I've done. The issue does not appear to be server-load related. It instead appears to be Android related with an extra unknown factor (possibly involving the hosting server - but I'm unsure). Below is a list of particulars I have confirmed through reproducible results.
ArrowChat private message delivery failure particulars:
- * Test sessions were conducted without ArrowChat's push service.
- * The hosting server is running SSL/TLS on Apache httpd.
- * Chatroom dialog exchanges function reliably (i.e., no delivery failures) between mobile-to-desktop, desktop-to-mobile, desktop-to-desktop, and mobile-to-mobile scenarios.
- * Private message dialog exchanges function reliably (i.e., no delivery failures) between each of the above combinations *except* the desktop-to-mobile and mobile-to-mobile ones.
- * The aforementioned failure behavior is consistently repeatable on test devices running the following Android versions: Kitkat (v4.4), Nougat (v7.0), Oreo (v8.0) - Note: it is also repeatable on Android instances emulated by desktop computers.
- * Private message dialog exchanges do *not* fail when the mobile ArrowChat interface is loaded on a Windows-based personal computer via the following URL: site_address.com/public/mobile/
- * Private message dialog exchanges do *not* fail when messages to an Android mobile device are sent from arrowchat.com's own installation of ArrowChat at their own website.
- * Reinstallation of ArrowChat on the hosting server makes no difference - the problem persists!
- * CPU core load and load averages on the hosting server sustain at low levels overall and will not spike up as the mobile message failures occur.
- * No other systems, services, or applications on the hosting server demonstrate hesitancy or complication in any regard.
- * According to archives on this message board, other ArrowChat customers have experienced this very issue - but unfortunately I have not seen any determination of causation, much less any posted solutions.
- Note: New message alerts (i.e, red count badges) for both chatroom traffic and private messages always come through and update on the mobile devices during my Android tests. It is exclusively the private chat message delivery function in the real-time sessions that's afflicted by this intermittency. Refreshing the mobile browser tab consistently pulls the complete history of intact private messages from the database
Thanks
-
zoxtrix - Customer
- Posts: 74
- Joined: 29 Jun 2019, 19:31
BTW, I forgot to mention two additional behaviors...
First, the 'is typing' animation does in fact appear on the recipient's mobile screen as soon as the sender begins typing one of the messages that ultimately fails to come through on the mobile session. And that typing indicator remains on-screen for approximately 30 seconds at which point it times out and vanishes without showing the sender's message that triggered it.
Next, I can dramatically decrease the frequency of message transfer failures by setting the message heartbeat interval to below 1 second (e.g., 0.5 or even 0.25). While not practical to maintain - since it calls for significant server resources - it's a test that proves two things. 1) My server handles the extra load very well (lightning fast transfer on the messages that come through. And 2) that significantly more of the messages sent to the mobile devices are in fact delivered than when the heartbeat interval is set to a higher value.
I'm hoping the above observations may be useful in assessing this issue's causation.
First, the 'is typing' animation does in fact appear on the recipient's mobile screen as soon as the sender begins typing one of the messages that ultimately fails to come through on the mobile session. And that typing indicator remains on-screen for approximately 30 seconds at which point it times out and vanishes without showing the sender's message that triggered it.
Next, I can dramatically decrease the frequency of message transfer failures by setting the message heartbeat interval to below 1 second (e.g., 0.5 or even 0.25). While not practical to maintain - since it calls for significant server resources - it's a test that proves two things. 1) My server handles the extra load very well (lightning fast transfer on the messages that come through. And 2) that significantly more of the messages sent to the mobile devices are in fact delivered than when the heartbeat interval is set to a higher value.
I'm hoping the above observations may be useful in assessing this issue's causation.
-
zoxtrix - Customer
- Posts: 74
- Joined: 29 Jun 2019, 19:31
What's the cleanest way to disable the 'is typing' indicator function for mobile devices? The call for and execution of the animated typing indicator seems related to the intermittent message delivery failure on Android devices I'm seeing. I'd like to disable it as a test to learn if doing so might serve as a workaround.
I tried removing the following portion of code from mobile_core.dev.js but it made no difference. The typing indicator still displays for 30 seconds then vanishes. Moreover, changing the "30000" to another value as well makes no difference. I could use some guidance here. I'd like to somehow get this plugin to work properly.
I tried removing the following portion of code from mobile_core.dev.js but it made no difference. The typing indicator still displays for 30 seconds then vanishes. Moreover, changing the "30000" to another value as well makes no difference. I could use some guidance here. I'd like to somehow get this plugin to work properly.
- Code: Select all
function receiveTyping(id) { var container = a("body")[0].scrollHeight - a("body").scrollTop() - 100; var container2 = a("body").outerHeight(); if (a("#arrowchat_user_" + id).length) { a("#arrowchat_user_" + id).append('<div class="arrowchat_message_wrapper arrowchat_clearfix" id="arrowchat_typing_message_' + id + '"><div class="arrowchat_$ if (container <= container2) { scrollOnPage2(); } clearTimeout(typingTimeout); typingTimeout = setTimeout(function () { receiveNotTyping(id) }, 30000); } } function receiveNotTyping(id) { if (a("#arrowchat_user_" + id).length) { clearTimeout(typingTimeout); if (a("#arrowchat_typing_message_" + id).length) { a("#arrowchat_typing_message_" + id).remove(); } } }
-
zoxtrix - Customer
- Posts: 74
- Joined: 29 Jun 2019, 19:31
Well, I've found that removing lines 102 thru 171 from functions_receive.php disables the typing indicator function. Unfortunately, the intermittent message delivery failure issue persists even still. In fact, it seems to occur just as frequently without the typing indicator function enabled. At least that's the result from the way I found to disable it. So much for that theory.
For me, the big concern about these intermittent delivery failures on mobile devices is that when you are attempting to conduct a 1-to-1 mission-critical conversation with someone and there's near certainty that some of your messages to that person will not be received, and additionally that the individual will be unable to know you've even sent them those messages because this random delivery failure issue keeps them from appearing within the destination device's live chat session history, serious consequences may well ensue. I am therefore disinclined to make ArrowChat available to our small user base unless and until this issue can be resolved.
Having stated the above, if anyone has a code modification I can try, I'm willing.
The other thing I'm wondering about is whether this problem is present on many others' non-push service installations of ArrowChat and they're simply unaware of it because they have never tried to send 20 or so labeled messages in a row to an Android test device. I do know that a handful of users have reported the issue (as can be seen in the following thread: arrowchat.com/forum/viewtopic.php?f=27&p=10449#p10449 ). Or perhaps it's that most folks are unconcerned about 10%+ of their messages to mobile devices not going through. Or maybe it's genuinely something related to my server that's causing the issue. I'm willing to examine that and other possibilities. Whatever the culprit, I'd love a solution!
Some feedback on this would be great.
For me, the big concern about these intermittent delivery failures on mobile devices is that when you are attempting to conduct a 1-to-1 mission-critical conversation with someone and there's near certainty that some of your messages to that person will not be received, and additionally that the individual will be unable to know you've even sent them those messages because this random delivery failure issue keeps them from appearing within the destination device's live chat session history, serious consequences may well ensue. I am therefore disinclined to make ArrowChat available to our small user base unless and until this issue can be resolved.
Having stated the above, if anyone has a code modification I can try, I'm willing.
The other thing I'm wondering about is whether this problem is present on many others' non-push service installations of ArrowChat and they're simply unaware of it because they have never tried to send 20 or so labeled messages in a row to an Android test device. I do know that a handful of users have reported the issue (as can be seen in the following thread: arrowchat.com/forum/viewtopic.php?f=27&p=10449#p10449 ). Or perhaps it's that most folks are unconcerned about 10%+ of their messages to mobile devices not going through. Or maybe it's genuinely something related to my server that's causing the issue. I'm willing to examine that and other possibilities. Whatever the culprit, I'd love a solution!
Some feedback on this would be great.
-
zoxtrix - Customer
- Posts: 74
- Joined: 29 Jun 2019, 19:31
So Jason, are you ignoring the issue I've presented herein? Or just very busy perhaps? Since you've not replied with as much as a suggestion for me to submit a support ticket, I'm feeling somewhat abandoned on my $295 AC business edition license purchase. I've done my best to provide details of the issue, yet you've provided zero feedback so far. Please advise.
Developments
1) Enabling debug error logging in bootstrap.php revealed one error involving includes/json/receive/receive_core.php. Fixing it required adding a "../" to the path directive on the first require_once line. But doing so had no effect on the message delivery failure issue.
2) I've discovered a new detail via adb console warnings for Android devices connected to my server's ArrowChat mobile provision. It's a warning that seems to indicate js source mapping isn't properly accessible. Below is the text from the warning:
Source map error: request failed with status 401
Resource URL: https://example_url.com/forum_name/arrowchat/public/mobile/includes/js/jquery-mobile.js
Source Map URL: jquery.mobile-1.4.5.min.map
Question:
Might this be relevant to the message failure issue? If so, might an older or newer version of jQuery resolve the matter? I'm quite clueless about what to try here.
Developments
1) Enabling debug error logging in bootstrap.php revealed one error involving includes/json/receive/receive_core.php. Fixing it required adding a "../" to the path directive on the first require_once line. But doing so had no effect on the message delivery failure issue.
2) I've discovered a new detail via adb console warnings for Android devices connected to my server's ArrowChat mobile provision. It's a warning that seems to indicate js source mapping isn't properly accessible. Below is the text from the warning:
Source map error: request failed with status 401
Resource URL: https://example_url.com/forum_name/arrowchat/public/mobile/includes/js/jquery-mobile.js
Source Map URL: jquery.mobile-1.4.5.min.map
Question:
Might this be relevant to the message failure issue? If so, might an older or newer version of jQuery resolve the matter? I'm quite clueless about what to try here.
-
zoxtrix - Customer
- Posts: 74
- Joined: 29 Jun 2019, 19:31
Update:
The 401 errors are intermittent and usually do not appear when the message delivery failure events occur. Considering they are authorization-based denied access warnings and that they appear at random intervals, it's hard to know why they're being generated. Maybe there's a latency issue going on related to the adb interface... I'm not sure. In any case, for now I'll assume the warnings are unrelated to the 1-to-1 message delivery failure problem.
Is this reasonable? If not, why?
What seems necessary for AC's mobile mode (when used without the push service) to work properly as far as ensuring that its 1-to-1 message delivery to mobile devices functionality is consistently reliable, would be the following: 1) It should poll the database for new data - I know it does already. 2) If the new data condition is not met and the existing timeout setting value has not yet elapsed, the polling event should run again. 3) The polling interval value and the timeout value should be manually adjustable. If they were, most servers could likely be configured to check more than once for a presence of new data prior to the timeout. I know that's a simplified view and that an efficient implementation may be somewhat complicated. But I also think mobile mode really needs it.
And a request:
If the above mechanism is already in place for mobile mode, please tell me how/where I can adjust the polling interval and timeout values.
Thank you
The 401 errors are intermittent and usually do not appear when the message delivery failure events occur. Considering they are authorization-based denied access warnings and that they appear at random intervals, it's hard to know why they're being generated. Maybe there's a latency issue going on related to the adb interface... I'm not sure. In any case, for now I'll assume the warnings are unrelated to the 1-to-1 message delivery failure problem.
Is this reasonable? If not, why?
What seems necessary for AC's mobile mode (when used without the push service) to work properly as far as ensuring that its 1-to-1 message delivery to mobile devices functionality is consistently reliable, would be the following: 1) It should poll the database for new data - I know it does already. 2) If the new data condition is not met and the existing timeout setting value has not yet elapsed, the polling event should run again. 3) The polling interval value and the timeout value should be manually adjustable. If they were, most servers could likely be configured to check more than once for a presence of new data prior to the timeout. I know that's a simplified view and that an efficient implementation may be somewhat complicated. But I also think mobile mode really needs it.
And a request:
If the above mechanism is already in place for mobile mode, please tell me how/where I can adjust the polling interval and timeout values.
Thank you
-
zoxtrix - Customer
- Posts: 74
- Joined: 29 Jun 2019, 19:31
Okay, Jason, here is our situation. I don't know how to fix this private message to mobile device random failure behavior. There's a bug report on this issue (or a very similar one) that was submitted 7 months ago (for v2.1). Its status designation still shows as "new." To me, this indicates no progress has occurred on resolving the matter but that you have acknowledged it as an issue. Logically, if you were aware of a fix for this apparent bug it would have presumably been resolved in v2.2 and you'd have provided feedback in the bug report dialog to that effect then changed the status to "fix completed." I would also think you'd have replied in *this* thread (or otherwise privately communicated to me) information on resolving the issue (if any existed). As far as I can tell, none of those responses has occurred, indicating there's currently no known way to correct the matter.
Based on the scenario described above, my sense is that this issue must be a difficult one to pin down. It stands to reason that you probably don't want ArrowChat to provide unreliable 1-to-1 messaging to mobile devices like this. And that's even considering that most of your customers may be using your push service (which seems to be immune to the bug) or that many of them not using your push service may be oblivious to the fact that 10 or 15 percent of the 1-to-1 messages they send to mobile devices may be failing to reach those devices during real-time chat sessions. We shouldn't have to wonder whether we need to refresh the page to see messages missed by the polling mechanism.
[Admin - Removed off-topic conversation]
Based on the scenario described above, my sense is that this issue must be a difficult one to pin down. It stands to reason that you probably don't want ArrowChat to provide unreliable 1-to-1 messaging to mobile devices like this. And that's even considering that most of your customers may be using your push service (which seems to be immune to the bug) or that many of them not using your push service may be oblivious to the fact that 10 or 15 percent of the 1-to-1 messages they send to mobile devices may be failing to reach those devices during real-time chat sessions. We shouldn't have to wonder whether we need to refresh the page to see messages missed by the polling mechanism.
[Admin - Removed off-topic conversation]
-
zoxtrix - Customer
- Posts: 74
- Joined: 29 Jun 2019, 19:31
What I have learned is that the receive_core.php file is key in transference of the real-time session data to the mobile interface. The following code seems like it may have bearing on the problem:
- Code: Select all
header("Content-Type: application/x-javascript"); echo $_GET['callback'] . '(' . json_encode($response) . ');'; flush(); close_session(); exit;
-
zoxtrix - Customer
- Posts: 74
- Joined: 29 Jun 2019, 19:31
** I HAVE A REQUEST FOR ARROWCHAT CUSTOMERS **
To anyone who is using any version of ArrowChat software with mobile mode, and who is NOT using ArrowChat's 'push service', I ask that you please conduct a simple test and then report back in this thread with the results.
Instructions
The test is quite quick and easy to perform. Using an instance of ArrowChat that is not utilizing the push service, merely establish a 1-on-1 message session with a mobile device and proceed to send a consecutive series of messages to that mobile device. You can use something like a separate alphabet letter or a sequential number in each test message. Send at least 20 separate messages, one after the other. What I want to know is whether any of those consecutive messages fail to arrive on the mobile device's ArrowChat session. Stated another way, if your using alphabet letters, please report back on how many of those letters (A thru Z) failed to come through on the mobile device during the test session.
I'm trying to learn whether the intermittent private message arrival failure I have been experiencing on mobile devices has a relatively isolated cause, or whether it's a common bug affecting everyone. Your help will be greatly appreciated.
Thank you in advance!
To anyone who is using any version of ArrowChat software with mobile mode, and who is NOT using ArrowChat's 'push service', I ask that you please conduct a simple test and then report back in this thread with the results.
Instructions
The test is quite quick and easy to perform. Using an instance of ArrowChat that is not utilizing the push service, merely establish a 1-on-1 message session with a mobile device and proceed to send a consecutive series of messages to that mobile device. You can use something like a separate alphabet letter or a sequential number in each test message. Send at least 20 separate messages, one after the other. What I want to know is whether any of those consecutive messages fail to arrive on the mobile device's ArrowChat session. Stated another way, if your using alphabet letters, please report back on how many of those letters (A thru Z) failed to come through on the mobile device during the test session.
I'm trying to learn whether the intermittent private message arrival failure I have been experiencing on mobile devices has a relatively isolated cause, or whether it's a common bug affecting everyone. Your help will be greatly appreciated.
Thank you in advance!
-
Tripp - Customer
- Posts: 34
- Joined: 05 Apr 2012, 04:57
Happy to help.** I HAVE A REQUEST FOR ARROWCHAT CUSTOMERS **
To anyone who is using any version of ArrowChat software with mobile mode, and who is NOT using ArrowChat's 'push service', I ask that you please conduct a simple test and then report back in this thread with the results.
Instructions
The test is quite quick and easy to perform. Using an instance of ArrowChat that is not utilizing the push service, merely establish a 1-on-1 message session with a mobile device and proceed to send a consecutive series of messages to that mobile device. You can use something like a separate alphabet letter or a sequential number in each test message. Send at least 20 separate messages, one after the other. What I want to know is whether any of those consecutive messages fail to arrive on the mobile device's ArrowChat session. Stated another way, if your using alphabet letters, please report back on how many of those letters (A thru Z) failed to come through on the mobile device during the test session.
I'm trying to learn whether the intermittent private message arrival failure I have been experiencing on mobile devices has a relatively isolated cause, or whether it's a common bug affecting everyone. Your help will be greatly appreciated.
Thank you in advance!
[Admin - Removed off-topic conversation]
Started messaging the Co-Administrator on my community; started with "0" and immedately upon sending it, I got a red bar along the top of the chat reading "There was an error sending your message. Try again later." I refreshed and tried again; same thing. She was on her mobile, and I was on my desktop.
I tried going:
- ~ "0 ABCDEFG"
~ "1 ABCDEFG"
~ "3 ABCDEFG"
... and so on.
She had received them all, except for "22 ABCDEFG", "23 ABCDEFG", "24 ABCDEFG", "48 ABCDEFG", "49 ABCDEFG" and "50 ABCDEFG" were all missing, except on refresh on her end, they all appeared in order.
Unrelated to this, I've found another bug. Sending just "0" to someone doesn't work. "00" does and "1", "2", "3", and so on also does. For some strange reason though just "0" doesn't.
-
zoxtrix - Customer
- Posts: 74
- Joined: 29 Jun 2019, 19:31
Hi Tripp... thanks so much for the reply!
It's interesting that the AC system won't allow a stand-alone zero character to be sent. I hadn't stumbled onto that glitch but I've just tested it and the same "There was an error sending your message. Try again later." response is returned.
As for your test strings, I've just attempted to duplicate them on my installation. I sent "0 ABCDEFG" through "30 ABCDEFG" to an Android mobile device from my desktop. All went through except "12 ABCDEFG", "15 ABCDEFG", "19 ABCDEFG", "24 ABCDEFG", "25 ABCDEFG", and "27 ABCDEFG".
Based on the comparison of our two sets of results using the same test string format, I think it's reasonably clear that the delivery failures are somewhat random. When I send each of the 26 alphabet letters, one at a time, I average 3 to 5 failures. Refreshing the mobile browser tab will always bring in the intact message history since it queries the database for it - failures never seem to occur with data sent to the database. The flaw seems to be with the polling/flush() mechanism that AC uses to check for and send messages to the real-time mobile 1-to-1 chat sessions. My guess is that the problem may lie somewhere within the two following files:
arrowchat/includes/functions/functions_receive.php
-OR-
arrowchat/includes/json/receive/receive_core.php
Or both of them.
[Admin - Removed off-topic conversation]
Thanks again so much for replying, Tripp!
It's interesting that the AC system won't allow a stand-alone zero character to be sent. I hadn't stumbled onto that glitch but I've just tested it and the same "There was an error sending your message. Try again later." response is returned.
As for your test strings, I've just attempted to duplicate them on my installation. I sent "0 ABCDEFG" through "30 ABCDEFG" to an Android mobile device from my desktop. All went through except "12 ABCDEFG", "15 ABCDEFG", "19 ABCDEFG", "24 ABCDEFG", "25 ABCDEFG", and "27 ABCDEFG".
Based on the comparison of our two sets of results using the same test string format, I think it's reasonably clear that the delivery failures are somewhat random. When I send each of the 26 alphabet letters, one at a time, I average 3 to 5 failures. Refreshing the mobile browser tab will always bring in the intact message history since it queries the database for it - failures never seem to occur with data sent to the database. The flaw seems to be with the polling/flush() mechanism that AC uses to check for and send messages to the real-time mobile 1-to-1 chat sessions. My guess is that the problem may lie somewhere within the two following files:
arrowchat/includes/functions/functions_receive.php
-OR-
arrowchat/includes/json/receive/receive_core.php
Or both of them.
[Admin - Removed off-topic conversation]
Thanks again so much for replying, Tripp!
-
Tripp - Customer
- Posts: 34
- Joined: 05 Apr 2012, 04:57
No problem. I'm going to go ahead and agree with your insight as to what's failing.Hi Tripp... thanks so much for the reply!
It's interesting that the AC system won't allow a stand-alone zero character to be sent. I hadn't stumbled onto that glitch but I've just tested it and the same "There was an error sending your message. Try again later." response is returned.
As for your test strings, I've just attempted to duplicate them on my installation. I sent "0 ABCDEFG" through "30 ABCDEFG" to an Android mobile device from my desktop. All went through except "12 ABCDEFG", "15 ABCDEFG", "19 ABCDEFG", "24 ABCDEFG", "25 ABCDEFG", and "27 ABCDEFG".
Based on the comparison of our two sets of results using the same test string format, I think it's reasonably clear that the delivery failures are somewhat random. When I send each of the 26 alphabet letters, one at a time, I average 3 to 5 failures. Refreshing the mobile browser tab will always bring in the intact message history since it queries the database for it - failures never seem to occur with data sent to the database. The flaw seems to be with the polling/flush() mechanism that AC uses to check for and send messages to the real-time mobile 1-to-1 chat sessions. My guess is that the problem may lie somewhere within the two following files:
arrowchat/includes/functions/functions_receive.php
-OR-
arrowchat/includes/json/receive/receive_core.php
Or both of them.
Thanks again so much for replying, Tripp!
[Admin - Removed off-topic conversation]
-
Jason - Customer
- Posts: 2329
- Joined: 12 Dec 2009, 16:06
Edited posts to remove the off-topic parts. Stay on topic, please. I will be forced to lock this thread if it continues to veer off-topic.
-
zoxtrix - Customer
- Posts: 74
- Joined: 29 Jun 2019, 19:31
While this may or may not be helpful, on the chance that it could evolve our discussion in a positive way, I will express what follows.
I experimented with some minor adjustments to the receive_core.php file. Among those adjustments, I tried altering the order of the fetchMessages(), getTyping(), and echo/flush code lines. I was hoping that the order in which these items were parsed may have some positive effect. Unfortunately it did not. I did learn that removing the getTyping() call and the if (!isset($_SESSION['typing'])) conditionals seems to be a good way to disable the typing notifications (for testing purposes). I also tested the following minor changes (which as well made no difference).
I changed:
I experimented with some minor adjustments to the receive_core.php file. Among those adjustments, I tried altering the order of the fetchMessages(), getTyping(), and echo/flush code lines. I was hoping that the order in which these items were parsed may have some positive effect. Unfortunately it did not. I did learn that removing the getTyping() call and the if (!isset($_SESSION['typing'])) conditionals seems to be a good way to disable the typing notifications (for testing purposes). I also tested the following minor changes (which as well made no difference).
I changed:
- Code: Select all
$result = $db->execute(" SELECT userid, last_message FROM arrowchat_status WHERE hash_id = '" . $db->escape_string($hash_id) . "' "); if ($result AND $db->count_select() > 0) { $row = $db->fetch_array($result); $last_message = $row['last_message']; $userid = $row['userid']; } else { $userid = NULL; }
- Code: Select all
$result = $db->execute(" SELECT userid, last_message FROM arrowchat_status WHERE hash_id = '" . $db->escape_string($hash_id) . "' "); if ($result AND $db->count_select() > 0) { $row = $result->fetch_array(MYSQLI_BOTH); $last_message = $row['last_message']; $userid = $row['userid']; } else { $userid = NULL; }
- Code: Select all
fetchMessages(); } header("Content-Type: application/x-javascript"); echo $_GET['callback'] . '(' . json_encode($response) . ');'; flush(); close_session(); exit;
- Code: Select all
fetchMessages(); } header('Content-Type: text/event-stream'); header('Cache-Control: no-cache'); $message=$_GET['callback'] . '(' . json_encode($response) . ')'; echo "data: $message"; close_session(); exit;
-
zoxtrix - Customer
- Posts: 74
- Joined: 29 Jun 2019, 19:31
Update:
I've tried a number of code substitutions and manipulations, none of which have rendered success in eliminating the frequent failure of user-to-user messages to reach their destination mobile devices. However, I now very much suspect the culprit lies among the fetchMessages() function code from the functions_receive.php file. Here is that code:
I've tried a number of code substitutions and manipulations, none of which have rendered success in eliminating the frequent failure of user-to-user messages to reach their destination mobile devices. However, I now very much suspect the culprit lies among the fetchMessages() function code from the functions_receive.php file. Here is that code:
- Code: Select all
function fetchMessages() { global $db; global $response; global $userid; global $messages; global $last_message; global $block_chats; global $heart_beat; $time_it = time(); $result = $db->execute(" SELECT arrowchat.id, arrowchat.from, arrowchat.to, arrowchat.message, arrowchat.sent, arrowchat.read, arrowchat.user_read FROM arrowchat WHERE arrowchat.to = '" . $db->escape_string($userid) . "' AND (arrowchat.read != 1 OR arrowchat.user_read != 1 OR arrowchat.sent > (" . $time_it . " - " . $db->escape_string($heart_beat) . " - 1)) ORDER BY arrowchat.id ASC "); $id_check = 0; $messages_test = false; if (!is_array($_SESSION['tab_alert'])) { $_SESSION['tab_alert'] = array(); } while ($chat = $db->fetch_array($result)) { $self = 0; $old = 0; if ($chat['from'] == $userid) { $chat['from'] = $chat['to']; $self = 1; $old = 1; } if ($chat['user_read'] == 1 AND $chat['read'] == 1) { $old = 1; } $chatid = $chat['from']; if (!empty($last_message)) { if (preg_match("#:$chatid/[0-9,a-z]+#", $last_message, $matches)) { $matches2 = explode("/", $matches[0]); $num = (int)$matches2[1]; $time_check = time(); if ($num < $time_check AND $chat['read'] != 1 AND $chat['user_read'] != 1) { $last_message = str_replace($matches[0], ":".$chatid."/".time()."", $last_message); } else { $last_message = $last_message; } } else { $last_message .= ":".$chatid."/".time(); } } else { $last_message = ":".$chatid."/".time(); } $chat_message = $chat['message']; $chat_message = str_replace("\\'", "'", $chat_message); $chat_message = str_replace('\\"', '"', $chat_message); $chat_message = clickable_links($chat_message); $block_chats_unserialized = unserialize($block_chats); if (!is_array($block_chats_unserialized)) { $block_chats_unserialized = array(); } if ( !in_array($chat['id'], $_SESSION['tab_alert']) ) { if ($old != 1) { if (!in_array($chat['from'], $block_chats_unserialized)) { $messages[] = array('id' => $chat['id'], 'from' => $chat['from'], 'message' => $chat_message, 'self' => $self, 'old' => $old, 'sent' => $chat['sent']); $messages_test = true; $_SESSION['tab_alert'][] = $chat['id']; } } } $id_check = $chat['id']; } if ($messages_test) { $response['messages'] = $messages; $db->execute(" UPDATE arrowchat SET arrowchat.read = '1' WHERE arrowchat.to = '" . $db->escape_string($userid) . "' AND arrowchat.id <= '" . $db->escape_string($id_check) . "' AND arrowchat.read = '0' "); $db->execute(" UPDATE arrowchat_status SET last_message = '" . $db->escape_string($last_message) . "' WHERE userid = '" . $db->escape_string($userid) . "' "); } }
-
zoxtrix - Customer
- Posts: 74
- Joined: 29 Jun 2019, 19:31
** My workaround for the mobile message delivery failure issue - I hope it is helpful to others **
This workaround amounts to a simple value adjustment in a single JavaScript file. All testing was performed on ArrowChat v2.2 (business license edition). The adjustment is quite simple to implement. Like me, you should notice an improvement immediately.
Instructions
(Warning! Before altering any file it is advisable to make a backup!)
1. Open the following file in a text editor: arrowchat/includes/js/arrowchat_mobile.js
2. Locate the function receiveCore() section, starting on line number 434
3. Scroll down to line 460 where you will find the following code:
This adjustment affects both the delay period for delivery of message notifications as well as the unknown factor that overwhelms the message delivery itself. Feel free to experiment with the values on this line if you like. But please be aware that my experimentation has indicated the 13000 * 1 value set seems optimal (at least on my server) in that it renders the least extent of message delivery failure.
This adjustment has in fact reduced the delivery failure of user-to-user ArrowChat messages sent from my server to mobile devices from 10%+ to less than 1%. To be more precise, my average failure rate on messages of this type is now only 0.96% - a dramatic improvement! I do not yet know if there are any negative side effects to be encountered from this adjustment. Hopefully Jason will chime in here sometime soon and perhaps provide us with his expert view in that regard. If I run into any undesirable behaviors that are seemingly attributable to this adjustment, I will surely report them here as well.
Important Note: I don't consider this a fix, because it is not one by strict definition. It is merely a temporary means of causing the user-to-user chat mode to deliver messages more dependably to mobile devices. Hopefully ArrowChat will incorporate a permanent and extensively tested fix for this bug in an upcoming release.
This workaround amounts to a simple value adjustment in a single JavaScript file. All testing was performed on ArrowChat v2.2 (business license edition). The adjustment is quite simple to implement. Like me, you should notice an improvement immediately.
Instructions
(Warning! Before altering any file it is advisable to make a backup!)
1. Open the following file in a text editor: arrowchat/includes/js/arrowchat_mobile.js
2. Locate the function receiveCore() section, starting on line number 434
3. Scroll down to line 460 where you will find the following code:
- Code: Select all
var CHT = c_heart_beat * 1000 * 3;
- Code: Select all
var CHT = c_heart_beat * 13000 * 1;
This adjustment affects both the delay period for delivery of message notifications as well as the unknown factor that overwhelms the message delivery itself. Feel free to experiment with the values on this line if you like. But please be aware that my experimentation has indicated the 13000 * 1 value set seems optimal (at least on my server) in that it renders the least extent of message delivery failure.
This adjustment has in fact reduced the delivery failure of user-to-user ArrowChat messages sent from my server to mobile devices from 10%+ to less than 1%. To be more precise, my average failure rate on messages of this type is now only 0.96% - a dramatic improvement! I do not yet know if there are any negative side effects to be encountered from this adjustment. Hopefully Jason will chime in here sometime soon and perhaps provide us with his expert view in that regard. If I run into any undesirable behaviors that are seemingly attributable to this adjustment, I will surely report them here as well.
Important Note: I don't consider this a fix, because it is not one by strict definition. It is merely a temporary means of causing the user-to-user chat mode to deliver messages more dependably to mobile devices. Hopefully ArrowChat will incorporate a permanent and extensively tested fix for this bug in an upcoming release.
-
zoxtrix - Customer
- Posts: 74
- Joined: 29 Jun 2019, 19:31
** My workaround for the mobile message delivery failure issue - I hope it is helpful to others **
. . . . . . .
. . . . . . .
- Code: Select all
var CHT = c_heart_beat * 13000 * 1;
Feel free to experiment with the values on this line if you like. But please be aware that my experimentation has indicated the 13000 * 1 value set seems optimal (at least on my server) in that it renders the least extent of message delivery failure.
Late Update
My further testing reveals that the message delivery failures lessen on a progressive basis as the first value on line 460 is increased. While I'm unsure where the point of diminishing returns may lie, I decided to increase this value by 1000 (milliseconds?) in each of my successive tests. When I reached 23000, I found that all of my test messages were transferring to the destination mobile device. That is, there were zero failures. So far, I've been able to duplicate this result multiple times. However, I'm not convinced that sending 500 test messages or so would not produce a few failures here and there... I just haven't encountered any since reaching the 23000 point. Overall, this has turned out to be an amazing improvement. The only issue I've encountered is that the initial notifications on the mobile tab are now delayed for up to 15 seconds from message send time - which I can live with. The messages themselves arrive instantaneously on the mobile test device.
Again, this adjustment is solely intended to temporarily workaround the bug. But it's a dramatic improvement!
-
Melanie - Customer
- Posts: 66
- Joined: 11 Jul 2011, 02:50
Zoxtrix,
I was just about to help testing as was reading through your messages but you seem to have solved it! Thank you so much for your perseverance and well done to get it working. It is really fast response on our devices.
Kind regards
I was just about to help testing as was reading through your messages but you seem to have solved it! Thank you so much for your perseverance and well done to get it working. It is really fast response on our devices.
Kind regards
-
zoxtrix - Customer
- Posts: 74
- Joined: 29 Jun 2019, 19:31
Hi Melanie,Zoxtrix,
I was just about to help testing as was reading through your messages but you seem to have solved it! Thank you so much for your perseverance and well done to get it working. It is really fast response on our devices.
Kind regards
A couple of things to be noted. First, I'm sad to say that the issue is definitely not solved. While the behavior seems greatly improved by the adjustment, this morning I did another battery of tests and the failures still occur - albeit they are fewer and further between now. Sometimes I can send over 150 messages without a failure, while other times a failure will happen after just 50 or so messages. That's still better than every 10th message (or so) like before. There is seemingly something very wrong with the receiveCore mechanism and it should really be corrected by ArrowChat. There is a bug report in on this issue. Hopefully they'll be able to sort it out prior to the next update.
If you still want to test this, I would be interested in your results. Thanks for your reply!
