We have a client computer that takes for every to launch a project every time. The client always receives the unpacking message when launching a project.
What would cause this to happen? is there some kind of log file on the workstation that i can look at to see what is going on when a project is launched?
Thank you,
Yeah, take a look at the user directory. There will be a folder in there called “.ignition”, this is where the client cache should reside. What do the contents of that directory look like?
You can also enable the java console on that computer (Windows Control Panel > Java > Advanced Tab > Java console > Show Console and launch and take a look at what the console output is.
It should find the old cached files and use those instead of re-downloading and re-unpacking. The console and/or .ignition directory may hold some clues.
Should the time to download and unpack the designer for the very first time take at least 30 minutes?
Is there anything we can do to speed this up? It looks like the cache on an already setup user is only about 230 MB and should not take that long to download on a LAN.
this following screen took at least 10 minutes just to get passed package 1
Thank you,
Good lord, no. Something is horribly wrong.
Java Version 6 Update 26
it does not seem to be a specific machine.
the majority of the time is when it is says “Package #/#, unpacking”
machine specs (one the client specs they vary)
Intel Cor 2 Duo CPU E8400 @ 3.00GHz
4 GB RAM
windows 7 64-bit
I think I know what is causing it through trial and error, but i do not have a solution. We have folder redirection setup through our domain for all our user’s user folders to a network share. when I try loading the designer or project on any machine with a folder redirection account the unpacking takes for ever. If i log in with an account without folder redirection the unpacking is super quick in comparison. any ideas how to troubleshoot or fix this theory?
Oh yeah, that makes perfect sense then. The bootstrap launcher uses a folder called ".ignition" under the user's home directory (usually something like "C:\Users\Jonathan" on Windows 7) to store the jar file cache. It downloads compressed jar files in pack200 format, writes those to disk, and then decompresses them, and writes the full jar file to disk as well.
Of course, if your user directory isn't on the local disk, you're going to be doing a bunch of network IO, which is what has to be taking the time.
I think we have two options going forward, but both will require us to make a change to the software. One is for us to investigate - there may be some IO buffering we can do to minimize the write calls. I'm assuming you've got reasonably fast network (gigabit?), in which case I wouldn't expect to see a slowdown of the magnitude you're describing.
If that fails, we'd have to add some option to be able to optionally specify an alternate cache directory.
Question (maybe for your IT dept): would it be difficult to place a file in every one's home dir? Perhaps the client could look for a file called ".ignition-client.prefs" or something that, if it is present, could point to an alternate cache dir. That way the setting could be set on a per-machine basis which might be desirable, as opposed to a global setting that affects all clients. (It would be tough to specify a good alternate location that would work on both linux clients vs windows clients for example).
Ok, I checked it out and sure enough, the pack200 unpacking process isn’t using any IO buffering, which might make a world of difference when going across a network. I’ll add that in and you can check it out in a 7.2.8 beta and see whether or not it helps.
Would it be possible to have Ignition download the cache to the local AppData folder instead of the root of the user folder?
Windows Environment Variable %LOCALAPPDATA%
Vista/7
c:\users%username%\AppData\Local
Windows XP
c:\Documents and Settings%username%\Local Settings\Application Data
I suppose that would be possible, but I don’t think there is a good platform independent way for me to ask Java for the location of the “local app data” dir because not all OSes have that construct, and I’m always very hesitant to add OS-specific logic, but it’s not out of the question.
How about using the following directory returned from this code in java?
System.getProperty("java.io.tmpdir");That one is a pain to find by hand and it is very volatile - OS might wipe it out if it feels like it.
Sorry - I like using the user directory. Lets see what difference some buffering makes - 7.2.8 beta 2 is on its way - check it out when it appears on the download page and see if it makes a difference. Because this is a (rare) change to the bootstrap launcher itself, you may need to clear your java cache (like the bad-old days of FactoryPMI JWS launching) to ensure you’re running the new launcher.
Thanks. I will give it a try. Since we still are in the process of switching to Ignition everyone around here is experts at clearing their java cache for Factory PMI.
The beta seemed to have sped things up. it takes about 3 minutes to launch the designer on a computer that has not been cached. as opposed to 30 minutes.
Ok, can’t complain about a 10x improvement just by adding some buffering. If that isn’t acceptably fast I think the next step would be to have a per-client config file that would specify an alternate cache dir.
3 minutes is fast enough for me.
Hi,
Was just reading this conversation and we seem to be having a similar problem, I am going to try all the suugestions you have made here but in addition what would the process be for the ‘per-client config file that would specify an alternate cache dir’?
That was just an idea I had for a potential feature we could add if the buffering wasn’t sufficient. There currently is no per-client config file for this setting, sorry.
I would like to revisit this issue. For the last few months everyone at our facility has been using Ignition. As I have been asking around about how everyone likes the new platform I have received comments that it is slower than our old FactoryPMI system.
I have found that if no changes have been made to a project the process of launching a client that has been cached takes anywhere from 20 seconds to 30 seconds on a user with folder redirection. On a user account that does not have redirection enabled the launching process takes between 3 to 5 seconds.
Now if a project gets updated, which we do constantly throughout the day to many projects, the launching process takes between 30 and 60 seconds on a folder redirected account. On a user with folder redirection disabled a non-cached project takes between 5 to 10 seconds to launch.
Most of our projects our linked through the use of retargeting and when someone switches to a project that has not been updated it is slow just like launching a non-cached project.
The two launch screens that seem to take the longest when launching a project is “Analyze Local Cache” and “Init Working Dir”.
Is there anything we can do to speed this process up since all our users have folder redirection setup?
Thank you,
Well, I looked through what goes on in those two steps, and I don’t think there is much we can do to speed it up. It’s all a bunch of File IO reading and writing to files in the cache.
The cache analyze step reads through each Jar and calculates a CRC for the jar to see if it needs to donwload a new version. The init working dir copies each jar to an temp dir to actually run off of so that the actual jars can be modified later without worrying about file locks.
Clearly this whole idea was based on the assumption that a user’s local dir is LOCAL to the client’s hard drive, and thus fast. I think we’ll have to have a way for you to put the .ignition folder elsewhere - there’s only so much speed we can eek out of the system when the drive is really located over the network.
Ok, as of 7.4.3, you can put a file called [tt]redirect.txt[/tt] in your USER_HOME/.ignition folder. It should have 1 line: a path to a different folder. This other folder will then be used as your home directory.
Hope this helps,