Did someone else faced issues with running Viper modules in parallel, in different windows?
Here is an example:
1) Operation 1 is starting and needs to read the file two times.
2) While running, it reads a file, per need. In a deparate window, a user starts Operation 2, with a different module for a different/same file.
3) Operation 2 is quite fast and ends, while Operation 1 still running.
As operation 2 ends __sessions__.close() is called, which sets self.current = None views.py(#261)
4) Operation 1 continues and reaches a point where for example needs to read the file again, as per needs. Example: xored = xordata(__sessions__.current.file.data, key) - which will fail, as sessions.current was destroyed one step ago.
I don't know if this is an expected behavior, or that the VIPER framework should not be used for parallel processing - so, if someone else faces this issue, feel free to join the party. Here is the fix that worked for me, in order to delay the 2nd, 3rd, etc processing and process them sequential:
views.py:
def module_cmdline(project=None, cmd_line=None, file_hash=None):
wait_counts = 0
while __sessions__.is_set():
time.sleep(3)
wait_counts+=1
print('Waiting for the session to become available')
if wait_counts >= 60:
return '<p class="text-danger">Was not able to acquire an available session. Please retry or restart the web server</p>'
html = ""
cmd = Commands()
split_commands = cmd_line.split(';')
.......
Did someone else faced issues with running Viper modules in parallel, in different windows?
Here is an example: 1) Operation 1 is starting and needs to read the file two times. 2) While running, it reads a file, per need. In a deparate window, a user starts Operation 2, with a different module for a different/same file. 3) Operation 2 is quite fast and ends, while Operation 1 still running. As operation 2 ends
__sessions__.close()is called, which setsself.current = Noneviews.py(#261) 4) Operation 1 continues and reaches a point where for example needs to read the file again, as per needs. Example:xored = xordata(__sessions__.current.file.data, key)- which will fail, as sessions.current was destroyed one step ago.I don't know if this is an expected behavior, or that the VIPER framework should not be used for parallel processing - so, if someone else faces this issue, feel free to join the party. Here is the fix that worked for me, in order to delay the 2nd, 3rd, etc processing and process them sequential:
views.py: