Dear Scott,
Am 11.08.14 um 05:36 schrieb C. Scott Ananian:
What seems like a deadlock may in fact be parsoid timing out while trying to connect to your local wiki's API end point. We have had some users report problems of this sort which were caused by their firewall or access control setup. You might want to verify that the API end point for your local wiki is configured correctly, and that you can successfully connect to it from the machine Parsoid is running on.
thanks for the input, but all services (Wiki (apache2), mysql and Parsoid) are running on the same machine.
Additionally, I used "tcpdumd -A ..." to capture the conversation between the Wiki (i.e. /wiki/api.php) and the Parsoid service, see detailed transcript in my original report, steps (3) to (7), and so verified that they can and do communicate. Logs available if needed.
Parsoid times out, but not due to a failed TCP connection.
@All: I am happy to provide any addition information regarding my setup and steps tried that you consider useful.
Best regards
Björn
On Sun, Aug 10, 2014 at 11:56 PM, Bjoern Kahl mls@bjoern-kahl.de wrote:
Am 10.08.14 um 20:52 schrieb Gabriel Wicke:
On 08/10/2014 04:10 PM, Bjoern Kahl wrote:
What could cause this behavior and how should I configure my system to prevent the deadlocks? If this is a Bug in either MediWiki or the VisualEditor or Parsoid, how to further investigate and fix it?
In case this is a private wiki:
Did you set $wgSessionsInObjectCache = true;
following the instructions at https://www.mediawiki.org/wiki/Extension:VisualEditor#Linking_with_Parsoid_i...
?
Yes, I have (and had) "$wgSessionsInObjectCache = true;" in my LocalSettings.php
I have just disabled it (set to false) to counter-check, and it does produce a different sequence of activities. On a first glance, it seems to stop earlier, but in the end process and answer three calls from Parsoid instead of zero.
I'll have a closer look tomorrow, for today it's to late (1 in the morning (1 CEST / 23 UTC))