Asyncore Threading issue when using eg.RestartAsyncore()

[techoguy]

Hi all,
I'm hoping someone can help me with my plugin and an error i'm getting in threader/Asyncore within EG.

Code: Select all

08:22:47   Exception in thread AsyncoreThread:
08:22:47   Traceback (most recent call last):
08:22:47     File "threading.pyc", line 532, in __bootstrap_inner
08:22:47     File "threading.pyc", line 484, in run
08:22:47     File "asyncore.pyc", line 202, in loop
08:22:47     File "asyncore.pyc", line 132, in poll
08:22:47   error: (10038, 'An operation was attempted on something that is not a socket')
08:22:47   

This error occurs when i open a number of sockets one after another in my SONOS plugin (see my signature link for the plugin location). On one computer this error never occurs, on another computer it happens all the time. The main issue i'm having is that the error is within asyncore and doesn't seem to flag or throw an exception in my code. I have put the exception handlers in the asyncore dispatcher but that doesn't change anything i'm still not catching the exception.

Everytime i create a new asyncore socket instance I call eg.RestartAsyncore() to make sure it's handled in the same loop.

Can anyone tell me what might going on or what I should look for?

Thanks in advance!

[techoguy]

So i think i found a solution. I'm not sure exactly why it works but so far it seems to solve my problem.

It seems if you call eg.RestartAsyncore() sequencially with too small of a delay between each call this error can be produced.

To solve this in my own code, I made sure that eg.RestartAsyncore() was only called after a certain time has passed.

so

Code: Select all

eg.RestartAsyncore()

was replaced with

Code: Select all

def RestartSonosAsyncore(self):
    eg.RestartAsyncore() 

#eg.RestartAsyncore()
try: 
    self.renewCallBack = eg.scheduler.CancelTask(globalRestartScheduler)
except:
    pass
globalRestartScheduler = eg.scheduler.AddTask(.1, self.RestartSonosAsyncore)

What this does is it creates an asynchronous delayed call to a function that calls eg.RestartAsyncore(). The call is delayed by 0.1 seconds. if my code calls this code again, it cancels the previous scheduler and creates a new delayed call. This means if my code ends up needing to call eg.RestartAsyncore() 5 times within 0.1 seconds, instead of calling it 5 times, it will call it once. This seems to have fixed my problem and works good so far.

[techoguy]

I was wrong. This does not solve the issue, it only reduces the amount of times it occurs.

Does anyone have any ideas why this would be happening? could it be a threading/variable issue?

Thanks!

[techoguy]

Does anyone else experience this issue? I have 3-4 computers I have tested and they all experience it. The slower machines seem to run into the issue quite a bit more though.

Any ideas?

Thanks!

[techoguy]

Just wanting to bump this thread.
The more i use EG the more this issue occurs. This happens about 1-2 times a day now for me.

Is anyone else seeing this at least or is it just me?

Thanks for the help.

[heggholmen]

I'm experiencing the same issue :/ The frequence varies...

[techoguy]

I'm experiencing the same issue :/ The frequence varies...

Hi heggholmen,
which plugins are you using when this occurs? Just curious if i can get more clues to the issue.

Thanks!

[heggholmen]

Hi,

I'm only using a few plugins;

Sonos
Webserver
MQTT Client

I will drop Webserver, since I don't need that for my use anymore.

Hope that we find a solution for this since my girlfriend is not happy when she can't just click on a "lamp swicth" when she want to listen to a predefined playlist or simliar on our sonos playbar


//Jan-Erik

[techoguy]

Hi heggholmen,

I hope a solution is found soon too. otherwise i'll end up abandoning EG. I have a wife that it all has to work for. I currently have set up EG to catch the error when it occurs and automatically restart so at least it starts working agian and then when a button is pressed a second time it usually does work. But, it does happen too much to completely rely on it for a good experience.

The thing that scares me is everything I keep adding to EG uses the asyncore module for IP communication which is why it keeps happening more and more for me.

My theory is that it has something to do with the asynchronous activity occurring so close together in these plugins. But i'm not familiar enough with python to know for sure how to fix it or to try something different within EG.

[krambriw]

Not much I can contribute on this one but I have never seen this with any of the plugins I have used during the years, many of the plugins are indeed importing asyncore. One thing though, try to create a python script where the exception is provoked. How much I even try, repeatedly using eg.RestartAsyncore(), nothing happens (on the other hand, I do not have Sonos and your plugin installed)

Code: Select all

for i in range (10000):
    eg.RestartAsyncore()
    
print 'ended'

[techoguy]

Hi Krambriw,

Thanks for the suggestion. I've done something like that.

This error has happened for me through other plugins as well. I primarily use the Insteon and Sonos plugins.
I have ran many tests and it seems that the error happens during an asyncore handler and the sockets are active. It's almost like something closes the active socket but the asyncore handler is still triggered. I have ran many tests to try and determine the cause or pattern but have found nothing.

During my development of the SONOS plugin I did actually notice that my code could have situations where eg.RestartAsyncore() was called frequently (basically like a loop like your example) and it did actually cause issues. But it was not just calling eg.RestartAsyncore, it was receiving and sending messages which means all the handle function calls were also active. The issue was if I tried to create many sockets during a restart (asynchronous actions) it would cause errors. So I had to create a function that made sure eg.RestartAsyncore() was only called after a certain idle time meaning it is only called if no sockets have been created for that time (the time is very short).

One thing that could be tested is to create a loop that is actively sending and receiving packets (creating new sockets for each send) as quickly as possible between two machines and see if it still occurs.

UPDATE:
just thinking out loud, I wonder if it has anything to do with receiving larger sized packets that require the plugin to "receive" 2-3 times to assemble a complete message? The hardest part about testing this now is that the error takes hours or days to occur, but every effort in trying to capture the error in an exception, or capturing a pattern in the code and states of the plugin have failed.