ssossossossosso

Forums

Covering OroCRM topics, including community updates and company announcements.  Subscribe

Forums Forums OroCRM OroCRM – Installation/Technical Issues or Problems "Synchronizer error", Clank – best practices?

This topic contains 9 replies, has 2 voices, and was last updated by  Aaron 3 years, 5 months ago.

  • Creator
    Topic
  • #23416

    Aaron
    Participant

    I installed Oro CRM on a digital ocean droplet, and am running it in production mode. For the most part the process was nice and smooth, but I have come across two stumbling blocks which are not addressed in the documentation, and I’m not sure how to resolve them.

    There is a “Synchronizer can’t connect to server.” error displayed when anyone logs in. I don’t see any corresponding errors in the apache2 or /app/logs/prod.log files, and I’m not sure what this error means.

    The second (possibly related) is that the suggested command to run the Clank server:

    Seems inadequate; the process stays attached to the terminal, has debug-ish output, and no process monitoring. To run it in production I have simply “nohup’d” it, and redirected input from /dev/null – but perhaps I am missing something? Is there a suggested php process monitor or other app/console command that is more production appropriate?

    Is there an upstart profile, or popular PHP process monitor I could adapt for it? I’m more used to the Ruby ecosystem where this kind of thing would be done with bluepill or god.

Viewing 9 replies - 1 through 9 (of 9 total)
  • Author
    Replies
  • #23417

    Yevhen Shyshkin
    Participant

    Hello, Aaron.

    For now Clank server should be started manually (as you said). I’m using app/console clank:server > /dev/null 2>&1 & to silence all output. We need to improve this behaviour and provide easier way to work with it.

    In general, if you want to daemonize clank server process, you should work with this command as with regular shell command and use any external tool or shell script to run it as a daemon (f.e. http://software.clapper.org/daemonize/).

    #23418

    Aaron
    Participant

    Thanks, Yevhen, although that still leaves me wondering about the “Synchronizer can’t connect to server.” error when any user logs in.

    In case other people stumble across this discussion before changes are rolled into the console command, here is the solution I’m using on Ubuntu/Linux:

    Create a shell file to launch the console command with nohup, and use absolute paths. Write the nohup output to get a pidfile.

    Then you can use monit (example monit config) to watch the pidfile and get basic process management.

    This should work on any *NIX system which monit works on.

    #23419

    Yevhen Shyshkin
    Participant

    “Synchronizer can’t connect to server.” error might appear if server port (default is 8080) is closed or filtered by firewall. Please, ensure that port is really opened f.e. using nmap:

    #23420

    Aaron
    Participant

    hmm, no, nmap reports the port is open:

    Also clank appears to be running fine:

    And nothing in prod.log or syslog relating to clank.

    #23421

    Yevhen Shyshkin
    Participant

    Ok, let’s check everything from the very beginning.

    Clank server parameters at app/config/parameters.yml:

    Please, ensure that client part of the application (browser) aware about websocket_host (i.e. this host must be resolved by client to server’s IP) and port is open for client.

    Init connection headers (can be found using firebug):

    Also you can trace request and response with any HTTP sniffer (f.e. Wireshark).

    Clank server output:

    If something not works – please, put here appropriate logs.

    #23422

    Aaron
    Participant

    Thanks for the details.

    The problem seems to be that on the browser a request to load a bundle is failing:

    In particular it is trying to load
    /bundle/orocrmrequest/js/embed.form.js

    Interestingly my install has no “orocrmrequest” directory in the bundles, so that explains the failure. . .I don’t know why my install doesn’t have it, however.

    Since I don’t know what is in that file, it may or may not cascade into the later error:

    According to firebug the ‘url’ variable isn’t defined when that gets called, which leads the client to attempt to open a websocket to a default of

    I had the breakpoint set wrong. ‘url’ is not undefined, it is being set to ‘127.0.0.1’ somewhere else in the code. I see a ‘127.0.0.1’ hardcoded on line 505 of the page:

    But I don’t know if that value is getting threaded through to the websocket request. I’m not really set up to debug minified js here.

    Regardless, it seems like the websocket request should open <the server>:8080 instead of 127.0.0.1:8080 Although the former may be passing tests if you are testing with the server on the local machine. . .

    So, what is up with that missing bundle file – should I attempt a new install on another machine and then copy the bundle over?

    #23423

    Aaron
    Participant

    Sooo I went out of the frying pan, into the frier.

    I decided to migrate to git tag 1.2.0-rc1 to see if the bundle issue was straightened out there.

    I pulled, checked out the relevant tag, updated composer deps, and then ran the console update. I got a giant fireball of fail back. I’m going to revert the VM to yesterday’s backup. . .

    #23424

    Yevhen Shyshkin
    Participant

    Hm… In template host has valid value:

    Just checked on the latest master – it uses host from parameters.yml. If you changed web socket parameters – please, update your cache (app/console cache:clear –env prod).

    As for update – please, remove app/cache/* and then run oro:platform:update.

    #23425

    Aaron
    Participant

    I think it is just a matter of documentation/defaults in the config file, then.

    config/parameters.yml should only have websocket_host = 127.0.0.1 if your server and client are on the same machine – otherwise that setting should be updated to reflect the server ip or dns, right? a default of #{env hostname} (or similar) might be more sensible, or explaining that value in the install documentation.

    After setting the line to websocket_host = the-host-dns-name and resetting the cache the error seems to be gone – many thanks!

    As for upgrading, I reset the VM to the previous image and tried again:

    running php app/console oro:platform:update –force succeeded this time, perhaps a test user had hit the site between my clearing the cache and attempting the update last time, since I was lazy and hadn’t stopped the server first.

    Thanks for all the help, and hopefully this thread is useful to people who run into the same error!

Viewing 9 replies - 1 through 9 (of 9 total)

You must be logged in to reply to this topic.