NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.

To learn about what's going on, see About the Archive Site.

RE: Many instances of LDM on the same machine

David,

Thanks for the info.

In fact I cannot told you the number of clients that want different files
from the same feed type because at this point this is not a true situation
but only an hypothetical situation (but could be a real situation in a near
future) that me and my group envisage.

Have a good week-end

Daniel

> -----Original Message-----
> From: David Knight [mailto:knight@xxxxxxxxxxxxxxxx] 
> Sent: 21 November, 2003 18:10
> To: Daniel.Lemay@xxxxxxxx
> Cc: knight@xxxxxxxxxxxxxxxx; ldm-users@xxxxxxxxxxxxxxxx
> Subject: Re: Many instances of LDM on the same machine
> 
> 
> Oh well, it was a thought. One other one. The default
> ldm port is 388. Perhaps you can start different ldm
> processes listening on different ports. Sorry don't
> know if this is supported or not. I don't see
> how else you could determin that the correct
> ldm proccess is answering the request - but I'm no expert... 
> Sounds to me like either you, or your clients, are going to 
> have to be a little flexible. How many different variations 
> of the same feed do you need? Good luck, David
> 
> > David,
> > 
> > The problem is that I cannot put the files into two differents FEED 
> > types. It is one of the constraints of the problem (Many different 
> > clients want differents products, but each client want them tagged 
> > with the same FEED type).
> > 
> > Regards,
> > 
> > Daniel
> > 
> > > -----Original Message-----
> > > From: David Knight [mailto:knight@xxxxxxxxxxxxxxxx]
> > > Sent: 21 November, 2003 17:36
> > > To: Daniel.Lemay@xxxxxxxx
> > > Cc: steve@xxxxxxxxxxxxxxxx; ldm-users@xxxxxxxxxxxxxxxx
> > > Subject: Re: Many instances of LDM on the same machine
> > > 
> > > 
> > > I see two options (since you don't want to use two machines).
> > > If you insert the products into the queue originally, then 
> > > you could insert each set of data as a seperate feedtype. If 
> > > this is an existing feed, that you need to split up, then you 
> > > could put a matching pattern in your pqact.conf and reinsert 
> > > the product into the queue using pqinsert and specifying a 
> > > different feedtype. Then just allow by feedtypes as usual. 
> > > Should work, haven't tried it. David
> > > 
> > > > It's really that they  SHOULDN'T get any data that is not
> > > intended to
> > > > them.
> > > > 
> > > > Daniel
> > > > 
> > > > > -----Original Message-----
> > > > > From: Steve Emmerson [mailto:steve@xxxxxxxxxxxxxxxx]
> > > > > Sent: 21 November, 2003 17:07
> > > > > To: Lemay,Daniel [CMC]
> > > > > Cc: ldm-users@xxxxxxxxxxxxxxxx
> > > > > Subject: Re: Many instances of LDM on the same machine
> > > > > 
> > > > > 
> > > > > Daniel,
> > > > > 
> > > > > >Date: Fri, 21 Nov 2003 16:45:47 -0500
> > > > > >From: "Lemay,Daniel [CMC]" <Daniel.Lemay@xxxxxxxx>
> > > > > >To: "'Steve Emmerson'" <steve@xxxxxxxxxxxxxxxx>
> > > > > >Subject: RE: Many instances of LDM on the same machine
> > > > > 
> > > > > The above message contained the following:
> > > > > 
> > > > > > Suppose that I'm in the following situation:
> > > > > ...
> > > > > > -I want to be sure that my "clients" can only 
> obtain the files
> > > > > > that
> > > > > > are intend for them. I don't want to rely on the fact they 
> > > > > will choose
> > > > > > themselves the subset of the feed I allow them. I know that
> > > > > I cannot
> > > > > > insert a regular expression in my ALLOW statement to
> > > restrict what
> > > > > > files they will have access.
> > > > > 
> > > > > That's an interesting situation (and one that I haven't
> > > considered).
> > > > > 
> > > > > Is it the case that each downstream site SHOULDN'T get the 
> > > > > other's data or that such feed-requests would merely be
> > > inefficient?
> > > > > 
> > > > > Regards,
> > > > > Steve Emmerson
> > > > > 
> > > 
> 

  • 2003 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the ldm-users archives: