Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Hue plugin - Async fix #394

Merged
merged 14 commits into from
May 3, 2019
Merged

Hue plugin - Async fix #394

Changes from 1 commit
Commits
Show all changes
14 commits
Select commit Hold shift + click to select a range
2b89d49
Merge pull request #3 from Schrolli91/develop
f-kessler Mar 3, 2019
1eae309
Add hue plugin
f-kessler Mar 3, 2019
04f98f2
fix for #375
f-kessler Mar 3, 2019
9432141
settings for hue added
f-kessler Mar 3, 2019
5fc8f92
Update CHANGELOG.md
f-kessler Mar 3, 2019
6332bd3
description for multicastAlarm RIC updated
f-kessler Mar 3, 2019
a360b1c
Update CHANGELOG.md
f-kessler Mar 3, 2019
f86aeb9
Update alarmHandler.py
f-kessler Mar 3, 2019
ea68fab
logging fixed
f-kessler Mar 14, 2019
b3e63af
deepcopy of alarm data moved to processAlarm
f-kessler Mar 14, 2019
07a69d5
comment updated
f-kessler Mar 14, 2019
b117066
moved copy into for loop
f-kessler Mar 14, 2019
9c0ed13
Merge branch 'develop' into hue-plugin
Mar 15, 2019
af887c2
enhancement for deepcopy
f-kessler Apr 25, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 6 additions & 5 deletions includes/alarmHandler.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -14,6 +14,7 @@
import time # timestamp

from includes import globalVars # Global variables
from copy import deepcopy

##
#
Expand All @@ -36,20 +37,20 @@ def processAlarmHandler(typ, freq, data):
@return: nothing
@exception: Exception if starting a Thread failed
"""
#copy objects to avoid issues if the objects will be changed by plugin's or during asynch/threaded processing
dctyp = deepcopy(typ)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ich glaube wenn wir an dieser Stelle kopieren, besteht das Problem weiterhin.
Denn alle Plugins greifen ja auf EXAKT die selbe Kopie zu - oder täusche ich mich?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Muss ich mir morgen mal ansehen.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

zumindest an dieser Stelle bringt es nichts wenn wir verhindern wollen, dass die Plugins sich gegenseitig die Daten verändern könnten.

Passenderweise müsste es dann wohl in die Schleife, die die Plugins aufruft, sodass jeder Plugin Aufruf eine eigene Kopie der Daten erhält.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Guter Punkt. Habe das mal umgebaut. Ich muss das aber noch auf meinem System testen.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@f-kessler Läuft stabil?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Irgendwas läuft da noch nicht richtig. Die Kopien werden offenbar auch überschrieben. Zumindest landen in der Datenbank viele Alarme mit der selben RIC. Ich habe zwei Vermutungen. Entweder es liegt daran, dass in Zeile 44 bereits der Thread erzeugt wird, aber noch mit original Objekten an dieser Stelle gearbeitet wird. Oder es liegt daran, dass die Kopien immer den selben Namen haben und das Kopieren die Kopie überschreibt.
Hast du vielleicht eine Idee dazu?

Copy link
Owner

@Schrolli91 Schrolli91 Mar 26, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So wie sich mir das darstellt, besteht dieses Problem nur beim data-Dict.

Schlimmer ist es jedoch, wenn Seiteneffekte auftreten, mit denen man nicht gerechnet hat, und dadurch Fehler verursacht werden. Dies kann auch in Python passieren. Dies kann dann geschehen, wenn Listen oder Dictionaries als Parameter übergeben werden.

Die anderen DeepCopys sind also vermutlich gar nicht notwendig.
Evtl reicht es schon das deepCopy direkt in den Funktionsaufruf zu setzen:
plugin.run(typ, freq, deepcopy(data)) ?
Somit würde dann wahrscheinlich die kopierte Variable nicht überschreiben werden, da es keine gibt.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Das ist eine gute Idee. Werde das mal am Wochenende bei mir umschreiben. Hatte inzwischen auch gute Ergebnisse mit einem deepcopy vor dem Aufruf des Threads und einem weiteren deepcopy in der for-Schleife erzielt. Dein Vorschlag ist aber deutlich eleganter als stumpf neue Objekte anzulegen.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bin leider erst neulich dazu gekommen deinen Vorschlag zu testen. Bin mit dem Ergebnis sehr zufrieden.

dcfreq = deepcopy(freq)
dcdata = deepcopy(data)
if globalVars.config.getboolean("BOSWatch","processAlarmAsync") == True:
logging.debug("starting processAlarm async")
try:
from threading import Thread
from copy import deepcopy
dctyp = deepcopy(typ)
dcfreq = deepcopy(freq)
dcdata = deepcopy(data)
Thread(target=processAlarm, args=(dctyp, dcfreq, dcdata)).start()
except:
logging.error("Error in starting alarm processing async")
logging.debug("Error in starting alarm processing async", exc_info=True)
else:
processAlarm(typ, freq, data)
processAlarm(dctyp, dcfreq, dcdata)


##
Expand Down