I've done some refactoring and rewriting of my +Agent, I will employ various
ways of fetching/setting remote data but the technique you've described
above will be prominent.
I've reviewed the **Ext* part in the manual and I will need something
different as I will have several nodes on each machine on different ports
(starting with simply localhost). I suppose I could have simply modified it
if I had had one node per machine?
Anyway, what would the whole procedure you've described look like if I have
two external nodes listening on 4041 and 4042 respectively but on localhost
both of them, and the E/R in question looks like this?:
(class +Article +Entity)
(rel aid (+Key +Number))
(rel title (+String))
(rel htmlUrl (+Key +String)) #
(rel body (+Blob))
(rel pubDate (+Ref +Number))
In this case I want to fetch article 25 - 50 sorted by pubDate from both
nodes (if additional relations are needed to facilitate the sorting feel
free to add them to the E/R).
So as far as I've understood it a (setq *Ext ... ) section is needed and
then the specific logic described in your previous post in the form of
something using *ext* or maybe *remote*?
On Wed, Apr 21, 2010 at 8:08 PM, Alexander Burger <a...@software-lab.de>wrote:
> On Wed, Apr 21, 2010 at 06:35:30PM +0200, Henrik Sarvell wrote:
> > At first my remotes will be on the same machine so yes they could all be
> > forked from the main process.
> That's all right. On the other hand, the remote processes might be
> different _programs_ (i.e. starting from a separate 'main', 'go' etc.),
> so I would rather expect them not to fork from the same process.
> On which machine(s) all these processes run at the end of the day
> doesn't matter. Can well be all on localhost.
> > I suppose that means they will start to block and what consequences will
> > there be? If very bad how do I prevent it in the best way?
> Blocking is no problem at all in this context. As we discussed in
> previous examples (and also as shown in the docu of *Ext and related
> functions), the remote server spawns a child process for each query
> request. Such a query can block if the central server doesn't eat away
> all results quickly enough, but this doesn't matter.
> - Alex
> UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe