Beijer Electronics (formerly QSI Corporation)

Manufacturer of Mobile Data and Human Machine Interface Terminals.
It is currently Tue Nov 21, 2017 8:23 pm

All times are UTC - 7 hours




Post new topic Reply to topic  [ 21 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Thu Dec 17, 2009 10:48 am 
Offline
User avatar

Joined: Mon Apr 09, 2007 10:50 am
Posts: 48
Location: Dayton, Ohio
Hi,

Getting this error (error code 9) on G70s (Qlarity 2.6) that seems to come directly after an HTTPClient ExecuteGet. The server never gets contacted, instead an Ethernet Error occurs (discovered using the EthernetError function). I can fairly consistently reproduce the error; it seems to occur regularly if there's a server problem that results in a timeout after an HTTP Request (i.e. the response comes late or not at all). It's not perfectly consistent; sometimes it will work flawlessly after the timeout without the error occurring, then suddenly stop working. Other times it stops almost immediately. And once the error occurs, every following HttpClient request using ExecuteGet fails the same way.

Rebooting the units clears up the issue, but I'd like to avoid it in the first place. Is there something I can do in the EthernetError function to reset the HttpClient object and avoid this?

Thanks
Doug


Top
 Profile  
 
PostPosted: Thu Dec 17, 2009 10:53 am 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
Is "No Free Local Channel" the precise wording of the error?

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
PostPosted: Thu Dec 17, 2009 11:01 am 
Offline
User avatar

Joined: Mon Apr 09, 2007 10:50 am
Posts: 48
Location: Dayton, Ohio
Yes, it is; actually the exact message that comes out of the errmsg[] method parameter is the Subject - "connection refused - no free local channel" errcode value is 9


Top
 Profile  
 
PostPosted: Thu Dec 17, 2009 1:13 pm 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
The only error message that I can find that looks like that is "UDP or RAW packet refused - no free local channel" (prior to 2.6 the message read "UDP packet refused - no free local channel")

However that message should only be raised if you are running a UDP (or RAW) server in your workspace. Do you by any chance have have some type of network server (accepts incoming packets) in your application.

Alternatively have you possibly called NetOpen with a foreign port of 0? This latter could be indirect, such as setting up an EthernetClientV2 object with a foreign port of zero.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
PostPosted: Thu Dec 17, 2009 1:51 pm 
Offline
User avatar

Joined: Mon Apr 09, 2007 10:50 am
Posts: 48
Location: Dayton, Ohio
As a matter of fact, yes. Here's a list of the objects we have that accept incoming ethernet traffic:

1. VirtualQlarity, combined with VQWebServer to allow remote control
2. FTPServerV2 for sending files to/from the unit
3. EthernetServerV2 (as net_udp) for sending commands to the unit (i.e. reboot, download mode, server ip). In fact, the server sends out heartbeats every 10 seconds notifying all units of the current server location.
4. httpClientV2 that is used extensively for driving screens.

There are no calls to NetOpen in our code. Is this something I'm doing wrong with the EthernetServerV2? If so, why does the error come out of the HttpClient?

I will add an EthernetError function to our EthernetServerV2 and monitor it for errors as well.


Top
 Profile  
 
PostPosted: Thu Dec 17, 2009 2:05 pm 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
There is a moderate chance that your EthernetServerV2 is leaking communication channels, in particular it would be easy to leak a UDP channel. (looking at the object we could definitely improve the documentation as regards UDP channels).

Even though UDP does not for a logical "connection" to the remote device, Qlarity allocates a "channel" for each logical UDP conversation (any series of one or more UDP packets with the same IP address and port on each end). These logical channels must be released or the system will eventually run out.

The easiest way to do that is to modify your data received function to call closeConnection at the end
Code:
func datareceived(channel as comm, data[] as byte, ipaddr[] as byte, foreignport as integer)
    'Do your stuff here
    CloseConnection(channel)
endfunc

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
PostPosted: Thu Dec 17, 2009 2:09 pm 
Offline
User avatar

Joined: Mon Apr 09, 2007 10:50 am
Posts: 48
Location: Dayton, Ohio
Ahh. OK.

Right now, the last thing I do in datareceived is:

Code:
NetClose(GetComMessageSource())


It always occurs because it's the last line immediately after a check error. I'm not sure how I came by this code, if it was via documentation or website. I will change to the above.

Also, in the EthernetError function is it OK to put that code snippet there as well?


Top
 Profile  
 
PostPosted: Thu Dec 17, 2009 2:24 pm 
Offline
User avatar

Joined: Mon Apr 09, 2007 10:50 am
Posts: 48
Location: Dayton, Ohio
Hey Jeremy,

Just before I uploaded your suggested changes I started getting this out of the EthernetServerV2 EthernetError:

"UDP or RAW packet refused - no free local channel" Error code -9 Channel 0.

Will upload the new build and post back success or failure!

Thanks for all the help.

Doug

Edited to fix Error message fat finger and wrong object type.


Last edited by Doug B on Thu Dec 17, 2009 2:45 pm, edited 2 times in total.

Top
 Profile  
 
PostPosted: Thu Dec 17, 2009 2:29 pm 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
Well by calling NetClose directly you should avoid the out of channels problem, although it might cause some problems with the EthernetServer, as its internal data structures would indicate that the channel is open even though it really isn't.

My gut feeling is that it isn't the HTTPClient object because it should get an error more like "No free transmission channel" when it is out. And the way we have things structured, if you are naturally running out of channels, you would tend to run out of TCP channels before you run out of UDP ones (the system supports 64 network channels, of which any 32 may be TCP).

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
PostPosted: Thu Dec 17, 2009 2:44 pm 
Offline
User avatar

Joined: Mon Apr 09, 2007 10:50 am
Posts: 48
Location: Dayton, Ohio
Hey Jeremy,

I added the CloseConnection(channel) to the datareceived (and EthernetError) on the EthernetServerV2, and I produced the same Error as before:

Quote:
UDP or RAW packet refused - no free local channel


I didn't have my logging turned on so I don't have the Channel or Error Code info, but it def appears to be coming out of the EthernetServerV2

Edit:

Once this error message comes from the EthernetServerV2, and I attempt to make an HTTP Request (executeGet) with the HttpClientV2, I get the error message "connection refused - No free local channel" out of the HttpClient object.


Top
 Profile  
 
PostPosted: Thu Dec 17, 2009 2:54 pm 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
Is the EthernetServerV2 instance enabled 100% of the time (and in globals?)

Here is where I would probably start trying to instrument what is going on -- if you already have a logging facility then this should be straightforward:

  • Import the EthernetServerV2 into your workspace so that you can tweak some of the private functions
  • To do so, press Ctrl+Shift+T, [New Template] -> "Copy the code of...." -> Select EthernetServerV2 from the drop list. Press [OK]
  • Go to the EthernetServerV2 code and Add the following pieces of logging: (replace Log with whatever is appropriate for your logging facility)
  • In CommAccept, before the call to AddToClientList, do: Log ("Packet from " + str(ipaddr) + ":" + str(fport) + " on channel " + str(socket))
  • In CommReceive, before DataReceived do: Log ("Data on channel" + str(channel))
  • In CloseConnection, at the top do: Log("Closing Channel " + str(channel))

Now, when you look at your log you should see one "Packet From" message followed by a "Data on" and a "Closing Channel" message for each channel opened. If not, then a leak exists somewhere.

I will admit, this one is a bit baffling to me.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
PostPosted: Thu Dec 17, 2009 2:58 pm 
Offline
User avatar

Joined: Mon Apr 09, 2007 10:50 am
Posts: 48
Location: Dayton, Ohio
Heh, sorry to be a pain in the rear. I'm about done for today but will do this bright and early tomorrow and let you know the results.

And again, I very much appreciate all the help and quick responses. We sell a lot of your G70s and it's nice to know your support is so strong.

Doug


Top
 Profile  
 
PostPosted: Thu Dec 17, 2009 3:55 pm 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
I am sorry that this is happening -- these are the kinds of things that keep me up at night when errors come out of code that looks like it should function correctly. I am going to head out as well. Good luck with this and I will be in tomorrow.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
PostPosted: Fri Dec 18, 2009 9:33 am 
Offline
User avatar

Joined: Mon Apr 09, 2007 10:50 am
Posts: 48
Location: Dayton, Ohio
Hey Jeremy,

OK, i've added this code. Here's what I'm seeing:

Prior to an HTTP Timeout (i.e. an executeGet that returns after the G70's timeout occurs), here's the data I see in the log:

Code:
Packet from [10,0,100,79]:59790 on channel 4099
Data on Channel 4099
Ethernet Received:
Com-Net Paging 20
12101
from 10.0.100.79
Closing Channel 4099
Packet from [10,0,100,79]:59791 on channel 4099

...And so on, with the port incrementing by one each time.


At this point, I cause an execute get to timeout:

Code:
About to executeGet
Get Executed on 10.0.100.79:12101/blahblahblah

Packet from [10,0,100,79]:59795 on channel 4099


<http timeout occurs here, and then I let the server finish responding>

At this point the log goes to:

Code:
Packet from [10,0,100,79]:59795 on channel 4099
Packet from [10,0,100,79]:59797 on channel 4100
Packet from [10,0,100,79]:59205 on channel 4101
Packet from [10,0,100,79]:59206 on channel 4102


...and so on with both the port (sometimes the port will jump. for instance it went from 50169 to 56004 then continue by 1s. Another time it went from 56012 to 52304) and channel increasing by one. Note that the close seems to have disappeared. So has the message that comes out of the EthernetServerV2's datareceived method.

EDIT: I forgot to mention that at this time, aside from ignoring the ethernetserver commands, the unit seems to be functioning fine. I.e. the http requests occur just fine.


Top
 Profile  
 
PostPosted: Fri Dec 18, 2009 9:44 am 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
EDIT: Fixed an error in my log line. There should be 2 calls to getEnableInfo. The first determines if the EthernetServer object is enabled. The second determines of the EthernetServer's parent (and all ancestors) are also enabled. The original post just detected the EthernetServer's status twice.


Hrmm, more and more mysterious.

I am a bit concerned that messages seem to dying in the EthernetServer object.

Tweak the CommAccept logging to print the enabled status:
Log ("Packet from " + str(ipaddr) + ":" + str(fport) + " on channel " + str(socket) + ". " + str(me) + " enabled: " + str(GetEnableInfo(me, GET_ENABLED)) + ", " + str(GetEnableInfo(me, GET_ZENABLED)) )

Lets see if the EthernetServer is getting disabled somehow, which would be the most likely cause of dropped messages. If the EthernetServer is still enabled, then there may be a serious interaction problem between the HTTPClient and the EthernetServer.

You might also want to add a bit of logging to EthernetError, ConnectionEstablished and ConnectionClosed just for completeness.

By the way the fact that the port number is incrementing is normal and not something I would worry about, that is simply how your remote device is choosing to transmit

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 21 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group