Client stops talking to server

As you say, quite difficult to debug.

The client has a boolean flag to indicate whether it is currently processing a "collectionInterval" so that we don't have 2 collections happening at the same time. If the event that indicates "collection complete" never gets raised then the client will never collect again.

At the moment I can't see why this event wouldn't get raised... but maybe we need a better way of indicating the collectionInterval is still processing...

I had similar problems some time ago, somewhere around 1.0.3 version, but later it was somehow fixed :) there was some modifications in talking to server since then?

Clients were hanging on some kind of responense waiting from server, but there was no action log on apache. When 'Register button' was clicked some times in a row client stayed in 'Sending Request' state for ~20 secs and then timeout appeared. Only restart helped to restore communication. I was guessing that client sended request correctly, but some underlying layer (soap? i don't know exactly how soap works) was stucked until restart. Maybe something down there is broken in extraordinary situations.

Generally i had only 4-5 such hangs during last 2-3 months on 1.0.3 - 1.0.4+filecorruption client versions. But when clients were crashing from time to time it was hard to separate those two situations.

Right now probably there is nothing to add in this subject. Maybe if some particular client(s) in future would stop talking to server more often, there will be some place to tests...

Hello,

Today same client stopped calling server again.
Maybe there is some nice place in code where I can add something like write_to_log("talking to server prodedure started") to check if there will be a such record in log every my communication interval, to check if there is some problem with client, or maybe with os itself?
Since connection speed is something 3kb/s (3g limit reached) there is no 100% sure that problems are caused by client itself.

You could change the Debug writes for Trace writes in Schedule.cs here: http://bazaar.launchpad.net/~xibo-maintainers/xibo/halley/annotate/head:/client/dotNET/Schedule.cs#L261

You could also look in your user.config for the xmdsLastConnection (I think that is the name) to see the last time XMDS successfully completed.

You could also add a text trace listener, which will log everything to a text file. See here http://wiki.xibo.org.uk/wiki/Turn_on_Debugging_in_the_Debug_Client_Build

Just after the line "Open the XiboClient.exe.config file and add the following:"

Hmm

there is no such record in user.config. Maybe exist only on debug build?

I've just modified two lines like that:

                System.Diagnostics.Trace.WriteLine("Collection Timer Ticked, but previous request still active", "XmdsTicker");
                return;
            }
            else
            {
                Application.DoEvents(); // Make sure everything that is queued to render does

                xmdsProcessing = true;

                System.Diagnostics.Trace.WriteLine("Collection Timer Ticked, Firing RequiredFilesAsync");

interval set to 90 on my test notebook. Last Access time in panel correctly incerasing every 1-2 minutes (some time slower when client need to load a mpeg during interval).
But there is no single record in logfile. Only Options Started when opening config.

Is it required to change compilation mode to debug to make it work? My idea was to compile client that is almost simillar to current one, buf if debug mode is needed i'm going to use it.

Try looking in XiboClient.exe.config in your installation directory

Have you modified the config as per the Wiki article I sent you?

You will not need to use the debug build as you have changed the objects to "Trace" which is included in the Release build.

Yes, there is such variable mentioned in XiboClient.exe.config, but it's empty. Should be even modified by client there? I thought that it's only a template used to produce user.config.

Looks like that:
            <setting name="XmdsLastConnection" serializeAs="String">
                <value />
            </setting>

So need I to follow wiki when modified Debug to Trace? I thought that I need it only when enabling whole debug infos, no those two by code modification.

Ok, after wiki tweak log appeared. Now i'm going to put in on problematic display and maybe something will appear there after some hours.
Still no luck with LastConnection ;)

I just checked, last connection will never be written - its not saved at runtime (sorry I didn't realise that).

But now you have the log working to file, hopefully we will get some meaningful information.

Right now i'm not able to put anything bigger than 100kb to remote client over that crappy connection.
So i think i'll close this thread until it will be operational again. If there will be some news in client server communication problems i'm going to reopen it..

Anyway thanks for log help :)

I've just readed 1.0.4 freezee thread and maybe there is a simple problem explanation. I'm using 2.0sp1 net framework as described in xibo requirements. As I said before, I think that problem is somewhere outside client itself, becuse there is probably no way to interrupt ticker in client if everything else works correctly.
So maybe that would be also cure for some performance issues, like quite longer mpegs loading time that on my notebook.
Maybe suggested (not miminal) version should be 3.5 instead of 2.0? I've installed 2.0 on my machines becuse I've assumed it's best version if wiki say so :)

Any ideas? :)

It's certainly not going to hurt to install 3.5, but we don't have any information as to why that client improved after installing 3.5 as in theory it should make no difference.

Alex

--- original message ---
From: "Bartek" <email address hidden>
Subject: Re: [Question #95848]: Client stops talking to server
Date: 3rd January 2010
Time: 7:40:48 pm

Question #95848 on Xibo changed:
https://answers.launchpad.net/xibo/+question/95848

    Status: Solved => Open

Bartek is still having a problem:
I've just readed 1.0.4 freezee thread and maybe there is a simple problem explanation. I'm using 2.0sp1 net framework as described in xibo requirements. As I said before, I think that problem is somewhere outside client itself, becuse there is probably no way to interrupt ticker in client if everything else works correctly.
So maybe that would be also cure for some performance issues, like quite longer mpegs loading time that on my notebook.
Maybe suggested (not miminal) version should be 3.5 instead of 2.0? I've installed 2.0 on my machines becuse I've assumed it's best version if wiki say so :)

Any ideas? :)

--
You received this question notification because you are a member of Xibo
Developers, which is an answer contact for Xibo.

This email carries a disclaimer, a copy of which may be read at http://learning.longhill.org.uk/disclaimer

Ok, thanks Aleks.

So i'm going to start from log stuff, and then if loop would be called correctly every collection interval, some net framework new version tests.

Alex, sorry for mistake.

Hi there Guys!

Xibo is an awesome project, congrats for such a good piece of work!

Anyway I am using a few Xibo 1.2.2 Windows Clients with an Ubuntu 10.10 server and Ubuntu 10.04LTS server. Everything goes pretty well beside that one problem...

I have been noticing, from time to time, some connection problems, the client "logged in" flag is going down (red), and I sure cannot tell why, ande because of what. Even sometimes it goes down for like one or two days, and then it comes up again. The Clients are located around a few small cities around mine, so i've been checking it the displays are ok, and they were. Everything from last flawless download was being displayed, and the client itself was ok (no error and crash), just the connection to servers.

I am using XiboClients 1.2.2 with XiboServer 1.2.2 (1.2.2.1 tar gz). Windows xp sp3 and Windows 7 HP on ubuntu 10.10. and 10.04 as i mentioned. Generally everything is ok, but i am concerned what is wrong with the connection. The funny thing is, that it happens only on some of the clients, and generally every client is almost the same configuration (no additional software, just xibo nad ultravnc, sometimes thightvnc). Besides, even if the flag goes down, and the client doesn't have connection to the server, i can ping it and even use vnc in local network, it does not say it is connected to the web, but it has its static ip like it should)...

If anyone can help where to start finding the solution, I would be glad and Thank You!

To be honest, I would love to donate Xibo project, i am Just a student, but If I earned some good money, I would! You guys rock!

To Bartek: I am from Poland too, If me or you could use some help from each other, feel free to send me a message rutaz(at)tlen.pl

Stay cool :)!