[evla-sw-discuss] Central server

Tue May 6 20:16:52 EDT 2008

That's a good point Bill.

I think the issue is that Bruce wants to stay away from file I/O at  
his level of the software.  I see no problem doing the I/O from the  
Java-land portion of the CMIB software (any blocking done at that  
high of level is done in separate threads and will not affect Bruce's  
tasks).  In other words, to the CMIB operation as a whole, I don't  
think there is any difference between using NFS or Tomcat's HTTP to  
get the data out (with NFS probably being more efficient if anything).

I've been experimenting with running a listener on one of the CMIBs  
in Penticton and haven't had any issues with it that I can tell.  I  
think this would also scale better should we decide to collect  
Station Board data from more than one Station Board at a time because  
data from all the CMIBs would have to funnel into the central  
listener machine before being written to disk.  It might be to our  
advantage to let NFS sort that out.

Kevin

On May 6, 2008, at 5:16 PM, Bill Sahr wrote:

> While I want to think more about the issues Kevin has raised, one
> point does confuse me.  Kevin, you speak of CMIBs writing data
> products to a mounted NFS filesystem.  I thought the whole point
> of the CMIB User Tasks in combination with Station Board Output
> Listener tasks was to avoid having CMIBs write data products
> directly to an NFS filesystem.  Has this concept been abandoned?
>
> Bill
>
> Kevin Ryan wrote:
>> Hi Michael,
>> Well, I thought I was thinking long term. :)
>> Maybe I was asking for the wrong thing.   We want to be able to  
>> point  to a directory (say /home/widar) and know that no matter  
>> what process  is accessing that directory, be it a GUI on  
>> someone's laptop far away  (via URL), or a CMIB writing data  
>> products via NFS to a file, it will  be the same location for  
>> everyone and everything.
>> What brought this up is the Test Executor GUI's that have  
>> directory  path fields.  Those paths are relative to the CMIB's  
>> boot server  (CMIBS don't have their own disks); the problem  
>> arises when we add  more boot servers.  If they all mounted the  
>> same /home/widar  directory, then it would not matter.
>> I'm pretty sure this is something that will be required (or at  
>> least  be handy) even on the final system for things like property  
>> and  configuration files and perhaps temporary CMIB data products  
>> for  maintenance/testing.  It would be nice to keep other things  
>> like the  web start applications in this directory also.
>> Does this make any more sense?  I should have said central   
>> 'directory' rather than 'server'.  How the James Gang implements  
>> this  directory would be up to them.
>> Kevin
>> On May 6, 2008, at 2:31 PM, Michael Rupen wrote:
>>> Hi Kevin,
>>>    are you thinking of the 4-station PTC or the 10-station  
>>> system  or beyond?
>>> In the long run it's not obvious to me that many of these files   
>>> should reside
>>> on a single central file system, though initially this may be  
>>> useful.
>>>
>>>            Michael
>>>
>>> On Tue, 6 May 2008, Kevin Ryan wrote:
>>>
>>>> Hi gang,
>>>>
>>>> This is more of a James question but I think that many on this list
>>>> might be interested in the outcome.
>>>>
>>>> Work on the WIDAR correlator TestExecutor software suite has gotten
>>>> me thinking about how (or if) we will implement a 'Central Server'.
>>>> We want configuration files (the ones that set up the various
>>>> correlator modes), data output files such as those generated by the
>>>> Station Boards during OTS testing, property files and the Java Web
>>>> Start GUI application files all to reside on one central file  
>>>> system
>>>> that is mounted by all processors in the correlator including  
>>>> each of
>>>> the 256 CMIBs.  ... I think.
>>>>
>>>> Presently, the Java Web Start application files and the system
>>>> property files reside on 'filehost'(?) at '/home/asg/www/widar'.
>>>> This translates to the URL 'http://www.aoc.nrao.edu/asg/widar/'  
>>>> used
>>>> by Java for access to these files.
>>>>
>>>> Also, presently, the CMIBs access a directory on 'cmibhost' (the  
>>>> CMIB
>>>> bootserver in Bruce & Kevin's office) called '/opt/widar' where
>>>> configuration files are kept for now.  When the system goes online
>>>> there will be more than one CMIB bootserver which will cause
>>>> confusion since there will no longer be a single central '/opt/ 
>>>> widar'
>>>> directory.
>>>>
>>>> It would be nice if we could combine the '/home/asg' and 'opt/ 
>>>> widar'
>>>> areas on 'filehost' and 'cmibhost' into one area common to (and
>>>> mounted on) all processors in the correlator.  This machine must  
>>>> also
>>>> be a web server.
>>>>
>>>> I don't think this machine should be one of the online units like
>>>> MCCC.  I don't even know if it has to reside in the correlator  
>>>> room,
>>>> but keep in mind that there will be occasions where CMIBs will be
>>>> writing output data products to it via NFS.
>>>>
>>>> Suggestions James or anyone?  Is this something that the  
>>>> mirrored (or
>>>> whatever it's called) 'filehost' at the VLA could do?  Does the  
>>>> EVLA
>>>> already have something like this running out there that we  
>>>> could  share?
>>>>
>>>> Kevin
>>>>
>>>> _______________________________________________
>>>> evla-sw-discuss mailing list
>>>> evla-sw-discuss at listmgr.cv.nrao.edu
>>>> http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss
>>>>
>>> _______________________________________________
>>> evla-sw-discuss mailing list
>>> evla-sw-discuss at listmgr.cv.nrao.edu
>>> http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss
>> _______________________________________________
>> evla-sw-discuss mailing list
>> evla-sw-discuss at listmgr.cv.nrao.edu
>> http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss