On my test server, using 2.0.6, I was able to update the OperationFactory.py file to change the separator. I'm about to go live with Sabernet, so I moved Sabernet to a production server and upgraded to version 2.0.7. I've got a couple new issues.
#1. I can't find the OperationFactory.py file in verison 2.0.7. Did that get moved/combined with some other file?
#2. The Heartbeat function keeps crashing after an undetermined period of time. This is the error I get:
Exception in thread Thread-6:
Traceback (most recent call last):
File "threading.pyc", line 460, in __bootstrap
File "sndcs\server\Heartbeat.pyc", line 21, in run
File "Pyro\EventService\Clients.pyc", line 81, in publish
File "Pyro\core.pyc", line 390, in __call__
File "Pyro\core.pyc", line 467, in _invokePYRO
File "Pyro\protocol.pyc", line 255, in bindToURI
ProtocolError: connection failed
After this error, the client needs to reconnect every 20 seconds or so. If I relaunch the Sabernet server, it works fine again for awhile.
Any suggestions, aside from going back to version 2.0.6?
Thanks,
Marty
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
How did you install 2.0.7? From the tarball? The OperationFactory.py file should still be there in the "sndcs" folder.
Do you have the Event Server running? Looks like it's trying to connect to the ES but can't. That's why the client's are reconnecting every 20 seconds... because they aren't receiving the heartbeats. Pyro comes with a nice utility that shows you the current state of the Name Server that is great for troubleshooting this type of thing. The command is named "nsc" (Name Server Control) or "pyro-nsc" depending on how you installed it. If you run the command "pyro-nsc listall" you should see something like this:
I installed from the exe file. I kind of thought it went a little easier than the first time. One line in the options of the exe setup asks if you want to autostart the Name server, I chose yes. I didn't realize it was only the Name server and not the Event server.
I uninstalled the exe server and reinstalled using the tarball after installing all the prerequisites. Ran the configure_sndcs.py and setup.py. Set up both the Name server and Event server as a Windows service.
I continue to have issues with the Heartbeat crashing even if no clients running. (same error message as before.)
I was also having issues with the web client switching a department from an actual job to training. (sorry I don't have the error message with me at home)
I flipped back to the server I have set up with 2.0.6 and everything still works fine.
Marty
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ahh.. now I understand. The new Windows Server installer installer uses py2exe to "compile" the code. The OperationFactory file is there but it's not in any editable for. It's in the library.zip file and it's a .pyc which it python byte code. Not editable. If you're going to need to customize the code then the Windows Server installer isn't going to work. You'll need to install from source as you've done.
The start_name_server option does actually start *both* the Name Sever and the Event Server.
Were you able to run the "nsc listall" command? I hoping that's going to shed some light on the problem.
-Seth
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was able to figure that out. I actually edited the source in the directory I unzipped the tarball into, changed OperationFactory.py and re-ran the setup.py install file. It compiled and it installed the updated file.
I tried uninstalling 2.0.7 and installing 2.0.6, thinking there may be something with the update, but I get the same heartbeat error.
The output from the Name server looks normal:
-------- Flat dump of namespace
:Pyro.EventService --> PYRO://10.204.0.2:7766/0acc000218ac6facf3541a9ffd7bd3a9
:Pyro.NameServer --> PYRO://10.204.0.2:9090/0acc000216e06facf1401b375205af15
:sndcs.DCSServer --> PYRO://10.204.0.2:7767/0acc000218406fad0666737efabb1671
:sndcs.Employee --> PYRO://10.204.0.2:7767/0acc000218406fad06578ed00b2b5102
:sndcs.Indirect --> PYRO://10.204.0.2:7767/0acc000218406fad0661d4f456780431
:sndcs.LaborDtl --> PYRO://10.204.0.2:7767/0acc000218406fad065c7dc783b8e925
:sndcs.LaborHed --> PYRO://10.204.0.2:7767/0acc000218406fad0659cc593dc77b4d
:sndcs.Operation --> PYRO://10.204.0.2:7767/0acc000218406fad065f6d44e9babbdd
:sndcs.ScrapCode --> PYRO://10.204.0.2:7767/0acc000218406fad066b5c5503fe9866
:sndcs.Terminal --> PYRO://10.204.0.2:7767/0acc000218406fad06625a189cfae5ea
--------- End dump
I'm thinking about trying it on another server. This server I'm installing it on is a Blackberry server as well. It has a service running on port 8080, so I've been setting up sndcs to run on port 8088. Could that be my issue? Is the heartbeat looking at port 8080?
Marty
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That Name Server output looks fine. I suppose that doesn't necessarily mean that the ES is actually running. Can you see the Event Server running in the process list. Or maybe see port 9090 open in netstat? Perhaps try connecting to 10.204.0.2 port 9090 with telnet or something.
The port 8080 conflict shouldn't be a problem. That is only the HTTP port that DCS Web listens on and shouldn't come into play with the issue we are having here.
-Seth
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There must be something weird going on with that particular server. I scrapped that install and moved over to another Windows 2000 server, installed the 2.0.7 version and everything seems to work fine. The only thing I can think of is that the Blackberry services were conflicting with Sabernet. All that server has on it is the Blackberry Enterpise Server, Primary DNS, and DHCP services. Other than that, it's clean.
I do have one other question. Although everything seems to be working fine on this other server, there is an error on the server that comes up when sitting idle on the main screen. I'm assuming it's normal because it happens at the same time as the screen refreshes.
Traceback (most recent call last):
File "C:\Webware-0.9.4\WebKit\ThreadedAppServer.py", line 448, in threadloop
handler.handleRequest()
File "C:\Webware-0.9.4\WebKit\HTTPServer.py", line 127, in handleRequest
HTTPHandler.__init__(self, self._sock, self._sock.getpeername(), None)
File "c:\python25\lib\SocketServer.py", line 522, in __init__
Traceback (most recent call last):
self.handle()
File "C:\Webware-0.9.4\WebKit\ThreadedAppServer.py", line 448, in threadloop
Traceback (most recent call last):
File "C:\Python25\lib\BaseHTTPServer.py", line 316, in handle
File "C:\Webware-0.9.4\WebKit\ThreadedAppServer.py", line 448, in threadloop
handler.handleRequest()
self.handle_one_request()
File "C:\Webware-0.9.4\WebKit\HTTPServer.py", line 127, in handleRequest
22923 2008-01-09 09:40:28 /images/interface/bluebutton.jpg
handler.handleRequest()
File "C:\Python25\lib\BaseHTTPServer.py", line 299, in handle_one_request
File "C:\Webware-0.9.4\WebKit\HTTPServer.py", line 127, in handleRequest
self.raw_requestline = self.rfile.readline()
HTTPHandler.__init__(self, self._sock, self._sock.getpeername(), None)
File "c:\python25\lib\socket.py", line 346, in readline
HTTPHandler.__init__(self, self._sock, self._sock.getpeername(), None)
File "c:\python25\lib\SocketServer.py", line 522, in __init__
File "c:\python25\lib\SocketServer.py", line 522, in __init__
data = self._sock.recv(self._rbufsize)
self.handle()
self.handle()
error: (10054, 'Connection reset by peer')
File "C:\Python25\lib\BaseHTTPServer.py", line 316, in handle
File "C:\Python25\lib\BaseHTTPServer.py", line 316, in handle
22926 2008-01-09 09:40:28 /images/interface/bluebutton.jpg
self.handle_one_request()
self.handle_one_request()
File "C:\Python25\lib\BaseHTTPServer.py", line 299, in handle_one_request
File "C:\Python25\lib\BaseHTTPServer.py", line 299, in handle_one_request
self.raw_requestline = self.rfile.readline()
self.raw_requestline = self.rfile.readline()
File "c:\python25\lib\socket.py", line 346, in readline
File "c:\python25\lib\socket.py", line 346, in readline
data = self._sock.recv(self._rbufsize)
data = self._sock.recv(self._rbufsize)
error: (10054, 'Connection reset by peer')
error: (10054, 'Connection reset by peer')
Thanks,
Marty
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That error message is being thrown by the built in HTTP server in Webware that a default installation uses. "Connection reset by peer" would mean that the web server is saying the client browser closed the connection before the server could finish sending it all of the information it requested. I believe you can cause this message sometimes by hitting the stop button in your browser or closing the browser completly after requesting a page. That is true of Apache and other web servers, not just the built-in one in Webware. That doesn't sound like what is happening with you though so I'm not sure what would be causing that.
Does the error message happen occasionally or on every page request? Do the pages load completely in the browser? What browser are you using?
Just an FYI... the built in HTTP server is not the only game in town. It's the simplest to set up and I've never really had any trouble with it myself. Webware apps can also be set up to use Apache, IIS, and others as the actual HTTP server if you prefer. It's just a little more complicated to set up. I've done Apache before but not IIS. If the pages actually load fine anyway you may be able to ignore the errors.
-Seth
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It would appear that I only get these error messages from a Windows 2000 machine running IE6. I do not get this error running IE7 on Windows XP nor Firefox on Windows XP. In addition, it only happens on the Active Employees List, every time it refreshes.
It doesn't seem to be causing any problems, everything displays fine. I think I'm just going to "look the other way".
Thanks,
Marty Westra
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just downloaded the tarballs from SourceForge to double check if they contain the OperationFactory.py file and they do. Are you still having trouble locating it?
-Seth
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm having some performance issues with the Sabernet Client. When I launch it, I get the splash screen and it could take 3-5 minutes to open at times. It hangs on "Loading Available Activity Sets". The client is installed with all the defaults, so it does not have the "sort by column headings" turned on, you mention that causes some overhead.
If I watch the mySQL log, the last query that gets run is where it's grabbing all the jobs and returning 6080 records.
SELECT opr.serialNum, opr.number, asm.number, job.number, job.itemNumber, job.itemDescription, asm.description, opr.description, job.priority, job.hidden, cust.customerId, cust.name, dept.code, tasks.code, tasks.description FROM Operation AS opr LEFT JOIN Assembly AS asm ON opr.assemblyObjId=asm.serialNum LEFT JOIN JobHed AS job ON asm.JobHedObjId=job.serialNum LEFT JOIN Customer AS cust ON job.customerObjId=cust.serialNum LEFT JOIN Department AS dept ON opr.departmentObjId=dept.serialNum LEFT JOIN Tasks AS tasks ON opr.tasksObjId=tasks.serialNum WHERE opr.complete=0 ORDER BY job.priority DESC
Are there any limits on how many jobs, employees, or labor entries? My original plan was to wipe everything out and reload every night, but management would like to have a history, so I can imagine the job and labor tables growing quite large.
Your thoughts?
Marty Westra
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The column_sorting option moves some of the CPU from runtime and moves it to the front end when the client is loading. The CPU cycles it saves are when adding and deleting operations while the client is running. If I recall correctly you are not going to be doing that since you are updating in batch at night. I would recommend setting column_sorting = True and see what that does for you.
Also, are you dropping the whole table and recreating them every night. Might want to make sure that the table indexes are also beaing created. If you're just deleting all of the records this probably isn't an issue.
There are no record limits anywhere in the system. Just make sure to set the Operation.complete field to True if you're not going to be clocking hours onto the jobs anymore that way the job will drop off of the available activity list so it doesn't keep growing.
-Seth
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oh, and I almost forgot to mention that 2.0.8 will include some performance improvements for the speed issues you are describing when column_sorting is turned off.
-Seth
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Seth,
On my test server, using 2.0.6, I was able to update the OperationFactory.py file to change the separator. I'm about to go live with Sabernet, so I moved Sabernet to a production server and upgraded to version 2.0.7. I've got a couple new issues.
#1. I can't find the OperationFactory.py file in verison 2.0.7. Did that get moved/combined with some other file?
#2. The Heartbeat function keeps crashing after an undetermined period of time. This is the error I get:
Exception in thread Thread-6:
Traceback (most recent call last):
File "threading.pyc", line 460, in __bootstrap
File "sndcs\server\Heartbeat.pyc", line 21, in run
File "Pyro\EventService\Clients.pyc", line 81, in publish
File "Pyro\core.pyc", line 390, in __call__
File "Pyro\core.pyc", line 467, in _invokePYRO
File "Pyro\protocol.pyc", line 255, in bindToURI
ProtocolError: connection failed
After this error, the client needs to reconnect every 20 seconds or so. If I relaunch the Sabernet server, it works fine again for awhile.
Any suggestions, aside from going back to version 2.0.6?
Thanks,
Marty
Hi Marty,
How did you install 2.0.7? From the tarball? The OperationFactory.py file should still be there in the "sndcs" folder.
Do you have the Event Server running? Looks like it's trying to connect to the ES but can't. That's why the client's are reconnecting every 20 seconds... because they aren't receiving the heartbeats. Pyro comes with a nice utility that shows you the current state of the Name Server that is great for troubleshooting this type of thing. The command is named "nsc" (Name Server Control) or "pyro-nsc" depending on how you installed it. If you run the command "pyro-nsc listall" you should see something like this:
-------------- START DATABASE
:Pyro.EventService --> PYRO://172.16.0.13:7768/ac10000d27a25d007aa5547c1ac7beee
:Pyro.NameServer --> PYRO://172.16.0.13:9090/ac10000d27955d0078f7547c16ceb6ec
:sndcs.DCSServer --> PYRO://172.16.0.13:7766/ac10000d7c2d6af6a68241496387569e
:sndcs.Employee --> PYRO://172.16.0.13:7766/ac10000d7c2d6af6a67bc90f64a47660
:sndcs.Indirect --> PYRO://172.16.0.13:7766/ac10000d7c2d6af6a680c90f66d34755
:sndcs.LaborDtl --> PYRO://172.16.0.13:7766/ac10000d7c2d6af6a67ec90f655493ef
:sndcs.LaborHed --> PYRO://172.16.0.13:7766/ac10000d7c2d6af6a67cc90f65451de0
:sndcs.Operation --> PYRO://172.16.0.13:7766/ac10000d7c2d6af6a67fc90f6609866d
:sndcs.ScrapCode --> PYRO://172.16.0.13:7766/ac10000d7c2d6af6a68441496317c0dd
:sndcs.Terminal --> PYRO://172.16.0.13:7766/ac10000d7c2d6af6a681c90f6722f9b8
-------------- END
Make sure that the EventServer entry is there and that it doesn't say something like 127.0.0.1 in the URI.
-Seth
Seth,
I installed from the exe file. I kind of thought it went a little easier than the first time. One line in the options of the exe setup asks if you want to autostart the Name server, I chose yes. I didn't realize it was only the Name server and not the Event server.
I uninstalled the exe server and reinstalled using the tarball after installing all the prerequisites. Ran the configure_sndcs.py and setup.py. Set up both the Name server and Event server as a Windows service.
I continue to have issues with the Heartbeat crashing even if no clients running. (same error message as before.)
I was also having issues with the web client switching a department from an actual job to training. (sorry I don't have the error message with me at home)
I flipped back to the server I have set up with 2.0.6 and everything still works fine.
Marty
Ahh.. now I understand. The new Windows Server installer installer uses py2exe to "compile" the code. The OperationFactory file is there but it's not in any editable for. It's in the library.zip file and it's a .pyc which it python byte code. Not editable. If you're going to need to customize the code then the Windows Server installer isn't going to work. You'll need to install from source as you've done.
The start_name_server option does actually start *both* the Name Sever and the Event Server.
Were you able to run the "nsc listall" command? I hoping that's going to shed some light on the problem.
-Seth
I was able to figure that out. I actually edited the source in the directory I unzipped the tarball into, changed OperationFactory.py and re-ran the setup.py install file. It compiled and it installed the updated file.
I tried uninstalling 2.0.7 and installing 2.0.6, thinking there may be something with the update, but I get the same heartbeat error.
The output from the Name server looks normal:
-------- Flat dump of namespace
:Pyro.EventService --> PYRO://10.204.0.2:7766/0acc000218ac6facf3541a9ffd7bd3a9
:Pyro.NameServer --> PYRO://10.204.0.2:9090/0acc000216e06facf1401b375205af15
:sndcs.DCSServer --> PYRO://10.204.0.2:7767/0acc000218406fad0666737efabb1671
:sndcs.Employee --> PYRO://10.204.0.2:7767/0acc000218406fad06578ed00b2b5102
:sndcs.Indirect --> PYRO://10.204.0.2:7767/0acc000218406fad0661d4f456780431
:sndcs.LaborDtl --> PYRO://10.204.0.2:7767/0acc000218406fad065c7dc783b8e925
:sndcs.LaborHed --> PYRO://10.204.0.2:7767/0acc000218406fad0659cc593dc77b4d
:sndcs.Operation --> PYRO://10.204.0.2:7767/0acc000218406fad065f6d44e9babbdd
:sndcs.ScrapCode --> PYRO://10.204.0.2:7767/0acc000218406fad066b5c5503fe9866
:sndcs.Terminal --> PYRO://10.204.0.2:7767/0acc000218406fad06625a189cfae5ea
--------- End dump
I'm thinking about trying it on another server. This server I'm installing it on is a Blackberry server as well. It has a service running on port 8080, so I've been setting up sndcs to run on port 8088. Could that be my issue? Is the heartbeat looking at port 8080?
Marty
That Name Server output looks fine. I suppose that doesn't necessarily mean that the ES is actually running. Can you see the Event Server running in the process list. Or maybe see port 9090 open in netstat? Perhaps try connecting to 10.204.0.2 port 9090 with telnet or something.
The port 8080 conflict shouldn't be a problem. That is only the HTTP port that DCS Web listens on and shouldn't come into play with the issue we are having here.
-Seth
Seth,
There must be something weird going on with that particular server. I scrapped that install and moved over to another Windows 2000 server, installed the 2.0.7 version and everything seems to work fine. The only thing I can think of is that the Blackberry services were conflicting with Sabernet. All that server has on it is the Blackberry Enterpise Server, Primary DNS, and DHCP services. Other than that, it's clean.
I do have one other question. Although everything seems to be working fine on this other server, there is an error on the server that comes up when sitting idle on the main screen. I'm assuming it's normal because it happens at the same time as the screen refreshes.
Traceback (most recent call last):
File "C:\Webware-0.9.4\WebKit\ThreadedAppServer.py", line 448, in threadloop
handler.handleRequest()
File "C:\Webware-0.9.4\WebKit\HTTPServer.py", line 127, in handleRequest
HTTPHandler.__init__(self, self._sock, self._sock.getpeername(), None)
File "c:\python25\lib\SocketServer.py", line 522, in __init__
Traceback (most recent call last):
self.handle()
File "C:\Webware-0.9.4\WebKit\ThreadedAppServer.py", line 448, in threadloop
Traceback (most recent call last):
File "C:\Python25\lib\BaseHTTPServer.py", line 316, in handle
File "C:\Webware-0.9.4\WebKit\ThreadedAppServer.py", line 448, in threadloop
handler.handleRequest()
self.handle_one_request()
File "C:\Webware-0.9.4\WebKit\HTTPServer.py", line 127, in handleRequest
22923 2008-01-09 09:40:28 /images/interface/bluebutton.jpg
handler.handleRequest()
File "C:\Python25\lib\BaseHTTPServer.py", line 299, in handle_one_request
File "C:\Webware-0.9.4\WebKit\HTTPServer.py", line 127, in handleRequest
self.raw_requestline = self.rfile.readline()
HTTPHandler.__init__(self, self._sock, self._sock.getpeername(), None)
File "c:\python25\lib\socket.py", line 346, in readline
HTTPHandler.__init__(self, self._sock, self._sock.getpeername(), None)
File "c:\python25\lib\SocketServer.py", line 522, in __init__
File "c:\python25\lib\SocketServer.py", line 522, in __init__
data = self._sock.recv(self._rbufsize)
self.handle()
self.handle()
error: (10054, 'Connection reset by peer')
File "C:\Python25\lib\BaseHTTPServer.py", line 316, in handle
File "C:\Python25\lib\BaseHTTPServer.py", line 316, in handle
22926 2008-01-09 09:40:28 /images/interface/bluebutton.jpg
self.handle_one_request()
self.handle_one_request()
File "C:\Python25\lib\BaseHTTPServer.py", line 299, in handle_one_request
File "C:\Python25\lib\BaseHTTPServer.py", line 299, in handle_one_request
self.raw_requestline = self.rfile.readline()
self.raw_requestline = self.rfile.readline()
File "c:\python25\lib\socket.py", line 346, in readline
File "c:\python25\lib\socket.py", line 346, in readline
data = self._sock.recv(self._rbufsize)
data = self._sock.recv(self._rbufsize)
error: (10054, 'Connection reset by peer')
error: (10054, 'Connection reset by peer')
Thanks,
Marty
That error message is being thrown by the built in HTTP server in Webware that a default installation uses. "Connection reset by peer" would mean that the web server is saying the client browser closed the connection before the server could finish sending it all of the information it requested. I believe you can cause this message sometimes by hitting the stop button in your browser or closing the browser completly after requesting a page. That is true of Apache and other web servers, not just the built-in one in Webware. That doesn't sound like what is happening with you though so I'm not sure what would be causing that.
Does the error message happen occasionally or on every page request? Do the pages load completely in the browser? What browser are you using?
Just an FYI... the built in HTTP server is not the only game in town. It's the simplest to set up and I've never really had any trouble with it myself. Webware apps can also be set up to use Apache, IIS, and others as the actual HTTP server if you prefer. It's just a little more complicated to set up. I've done Apache before but not IIS. If the pages actually load fine anyway you may be able to ignore the errors.
-Seth
Seth,
It would appear that I only get these error messages from a Windows 2000 machine running IE6. I do not get this error running IE7 on Windows XP nor Firefox on Windows XP. In addition, it only happens on the Active Employees List, every time it refreshes.
It doesn't seem to be causing any problems, everything displays fine. I think I'm just going to "look the other way".
Thanks,
Marty Westra
Hi Marty,
Those are interesting findings.,, thanks for doing that research. I would chalk it up to IE6 oddity.
-Seth
I just downloaded the tarballs from SourceForge to double check if they contain the OperationFactory.py file and they do. Are you still having trouble locating it?
-Seth
Seth,
I'm having some performance issues with the Sabernet Client. When I launch it, I get the splash screen and it could take 3-5 minutes to open at times. It hangs on "Loading Available Activity Sets". The client is installed with all the defaults, so it does not have the "sort by column headings" turned on, you mention that causes some overhead.
If I watch the mySQL log, the last query that gets run is where it's grabbing all the jobs and returning 6080 records.
SELECT opr.serialNum, opr.number, asm.number, job.number, job.itemNumber, job.itemDescription, asm.description, opr.description, job.priority, job.hidden, cust.customerId, cust.name, dept.code, tasks.code, tasks.description FROM Operation AS opr LEFT JOIN Assembly AS asm ON opr.assemblyObjId=asm.serialNum LEFT JOIN JobHed AS job ON asm.JobHedObjId=job.serialNum LEFT JOIN Customer AS cust ON job.customerObjId=cust.serialNum LEFT JOIN Department AS dept ON opr.departmentObjId=dept.serialNum LEFT JOIN Tasks AS tasks ON opr.tasksObjId=tasks.serialNum WHERE opr.complete=0 ORDER BY job.priority DESC
Are there any limits on how many jobs, employees, or labor entries? My original plan was to wipe everything out and reload every night, but management would like to have a history, so I can imagine the job and labor tables growing quite large.
Your thoughts?
Marty Westra
Hi Marty,
The column_sorting option moves some of the CPU from runtime and moves it to the front end when the client is loading. The CPU cycles it saves are when adding and deleting operations while the client is running. If I recall correctly you are not going to be doing that since you are updating in batch at night. I would recommend setting column_sorting = True and see what that does for you.
Also, are you dropping the whole table and recreating them every night. Might want to make sure that the table indexes are also beaing created. If you're just deleting all of the records this probably isn't an issue.
There are no record limits anywhere in the system. Just make sure to set the Operation.complete field to True if you're not going to be clocking hours onto the jobs anymore that way the job will drop off of the available activity list so it doesn't keep growing.
-Seth
Oh, and I almost forgot to mention that 2.0.8 will include some performance improvements for the speed issues you are describing when column_sorting is turned off.
-Seth
Hi Marty,
You might want to check out the 2.0.8 version that just got released... should speed up the loading of available activities at application start.
-Seth