Hi Marcel... > - How many targets can ACE scale to? I have over 2000 new users each > month, > > and probably about 20,000 active users > > Hard to tell exactly, but we've setup ACE in such a way that you can not > only create a single server for all the targets, but also create a master > server with several "relay" servers (which act like proxies) to spread the > load. >
It wasn't just the serving-up of distros I was wondering about... it was stuff like the UI. One thing that took my notice was the targets column in the admin UI (the one on the far right). I haven't actually tried it yet so I don't know if that list is loaded lazily, or what. Does it show all targets that ever existed? > It also depends a bit on the number of updates, size of bundles and how > often these targets poll for changes. > A new distro is produced once a fortnight. The maximum size of a distro is 35MB. I have control over the polling because I think I'll build the update UI into my app... but I would call the first time the update UI is shown and then when the user wanted to 'check for updates'. > > - How does target management work when users are behind common-or-garden > > ISPs with dynamic IPs etc? I don't really care about what each individual > > target is running, although it would be a nice feature to be able to > > remotely manage a given target. But this would be exceptional (maybe > > changing the logging on a particular user's target to diagnose some > problem) > > Right now, ACE keeps track of each individual target, but it can be setup > so any new target registers automatically and gets a specific software > distribution. > What's this feature called and can I read about it anywhere? > ACE uses a management agent, which polls the server using HTTP. So dynamic > IPs are no problem, and firewalls usually also not. > When you say 'polls'... any recurring 'poll' can be switched off, right? I just want to check for a new distro when the user asks for it (for now... I suppose a Chrome-like dream of fully automatic updates is one to consider). > > - How can this work with an installer? Ideally I'd like to install my > > entire product when the user downloads it and not have a two stage > > installation > > That is currently not supported, unfortunately, but it is definitely an > interesting use case that we should explore. We actually do have some > support for installing our deployment packages from a local filesystem, but > we cannot at this point make a seamless switch from local installation to > remote installation. I would not mind at all putting that on the roadmap > though. > My concern with two stage installers is that the user will become frustrated with another wait while the app initialises itself and downloads its latest code. Maybe it's a false fear. Maybe (I use IzPack) I can just write a plugin to the installer which contacts the ACE server... Apps with ACE agents work fine offline, right? I don't want a SimCity style situation on my hands ;) > > - My app runs a Jetty web server where the Update UI lies... how does > this > > work with ACE? Do I contact the ACE server API, or interact with the > agent > > bundles co-located on the same OSGi container? > > The management agent by default has an embedded scheduler that > periodically polls the server. Instead of that scheduler, you can also > directly invoke the update task from OSGi (it is a service). So your update > UI could do that, and disable the scheduler. > Any links to docs for this? Or is this 'read the code'? > I'm sure these answers have triggered more questions, so don't hesitate to > keep asking! :) > Will do, have done :) Assume you're at EclipseCon, hope it's going well. Dan
