Commander Task Status Shows "executing"
Good morning!
I am using 9.2 BarTender/Commander currently running as an Application. I have several (6) tasks set up (all the same) to print labels based on trigger files with up to 5 Batender processes (configured in BarTender Commander Handler Setup). It's all working except once in a while, I will have one of the tasks show as 'Executing' rather than 'Waiting For File' or 'File Found'. I have found that when I see 'Executing' it has stopped working. Nothing else will print, no other files will get renamed, etc. I believe this may be due, at least in part, to high volume as it only happens on our highest volume days. And by high volume, I mean it handles dozens of files an hour, often over 300 per day. To get it working again I have ended the CMDR.exe and Bartend.exe via Task Manager and restarted Commander. When this is down, people need it back up ASAP.
I have added logging via BarTender and I already had logging from Commander (it doesn't indicate what the problem is). Since this has only happened on very high volume days, it would be difficult for me to force it to occur. We are planning to upgrade to 10.0 soon (not soon enough!) - but in the interim, does anyone have any suggestions on configuration changes or additional logging that may help capture the issue? I have not modified my memory heap as suggested in the Commander troubleshooting document but wanted to wait until we upgrade when configuring this is done via BarTender/Commander.
Meanwhile, if this happens again, I have the additional logging and I know I can use Detection - Show All Running BarTenders. Just thinking that someone might have some suggestions to prevent this issue or better capture and correct the cause. Thanks!
Suzanne
I am using 9.2 BarTender/Commander currently running as an Application. I have several (6) tasks set up (all the same) to print labels based on trigger files with up to 5 Batender processes (configured in BarTender Commander Handler Setup). It's all working except once in a while, I will have one of the tasks show as 'Executing' rather than 'Waiting For File' or 'File Found'. I have found that when I see 'Executing' it has stopped working. Nothing else will print, no other files will get renamed, etc. I believe this may be due, at least in part, to high volume as it only happens on our highest volume days. And by high volume, I mean it handles dozens of files an hour, often over 300 per day. To get it working again I have ended the CMDR.exe and Bartend.exe via Task Manager and restarted Commander. When this is down, people need it back up ASAP.
I have added logging via BarTender and I already had logging from Commander (it doesn't indicate what the problem is). Since this has only happened on very high volume days, it would be difficult for me to force it to occur. We are planning to upgrade to 10.0 soon (not soon enough!) - but in the interim, does anyone have any suggestions on configuration changes or additional logging that may help capture the issue? I have not modified my memory heap as suggested in the Commander troubleshooting document but wanted to wait until we upgrade when configuring this is done via BarTender/Commander.
Meanwhile, if this happens again, I have the additional logging and I know I can use Detection - Show All Running BarTenders. Just thinking that someone might have some suggestions to prevent this issue or better capture and correct the cause. Thanks!
Suzanne
0
-
Desktop heap is the top candidate in my opinion. I wouldn't wait until you get v10 to increase it.
Why are you running 5 BarTender processes? Do you have 5 or more cores on your CPU? If not then there is little to be gained by the extra number of processes from a throughput point of view. Remember that each process will consume memory and can have X number of label formats loaded after a while increasing the memory load. If you have many label formats in use then this will contribute to memory resource issues. Version 10 will cure much of this for you with just default settings.
It's best practice to use locally installed printer drivers instead of a server/client install where the client side driver is where BarTender/Commander is running. Also, make sure that any Seagull printer drivers are up to date. The current version is v7.3.0 -
Just wanted to post an update to this. We upgraded from 9.2 to 10.0 and do not have the 'Executing' issue any more. I found an option in the new version (within the BarTender Commander Handler) to automatically restart if it stops and to automatically reprint if a print request fails. I am not sure if we have just not had this issue or if these settings cause it to be transparent to us as it restarts and/or reprints. I have seen nothing to indicate the problem in the logs - so I suspect it was just a 9.2 issue.
Anyway, just wanted to provide this information in case someone is having this issue and wondering if upgrading might help. Certainly helped for me.
Thanks!0 -
[quote name='smarkind' timestamp='1340653380' post='2663']
Just wanted to post an update to this. We upgraded from 9.2 to 10.0 and do not have the 'Executing' issue any more. I found an option in the new version (within the BarTender Commander Handler) to automatically restart if it stops and to automatically reprint if a print request fails. I am not sure if we have just not had this issue or if these settings cause it to be transparent to us as it restarts and/or reprints. I have seen nothing to indicate the problem in the logs - so I suspect it was just a 9.2 issue.
Anyway, just wanted to provide this information in case someone is having this issue and wondering if upgrading might help. Certainly helped for me.
Thanks!
[/quote]
We are running 10.x in a DEV environmet and have noticed this exact issue (just posted about it here http://seagullscientific.invisionzone.com/index.php?/topic/996-v10-crashingstalling/) ... we've already increased HEAP and will try to other settings you suggested.0
サインインしてコメントを残してください。
コメント
3件のコメント