Hi Alvise,
Ok, thanks, I've copied it and linked it from the xrootd page....
Pete
On Fri, Nov 26, 2004 at 04:35:25PM +0100, Alvise Dorigo wrote:
> Hi Pete,
> a new version of java client is at
>
> http://www.slac.stanford.edu/~dorigoa/XrdCopyFile_20041126.jar
>
> these are the fixes: OKSOFAR mechanism has been fixed and is working.
> These tests have been done deeply in SYNC mode and without making the
> server crash:
>
> 1. One server, 1 client reading
> 1b. One server, 1 client reading w/ oksofar
> 1c. One server, multiple clients reading w/ oksofar
> 2. One server, 1 client writing
> 3. One server, 1 client reading/writing
> 3a. One server, 1 client reading/writing w/ oksofar
> 4. One server, multiple clients reading
> 5. One server, multiple clients writing
> 6. One server, multiple clients reading/writing
>
> When I say reading/writing I mean that 1 or more clients read from a
> remote file through xrootd and write on another remote file always
> through xrootd (shortly: an xrdcp mono-threaded or multithreaded).
> When I say One server I mean only one dataserver and then only one
> physical channel on which the connection manager multiplexes 1 ore more
> clients. This ensures that the semaphore mechanism on the tcp channel
> works well.
>
> Alvise
>
> Peter Elmer wrote:
>
> > Hi Alvise,
> >
> > Very cool: accessing xrootd from cell phones! I've copied the jar file
> >into the xrootd area and made links from the xrootd page.
> >
> > thanks,
> > Pete
> >
> >On Thu, Nov 25, 2004 at 10:22:57AM +0100, Alvise Dorigo wrote:
> >
> >
> >>Hi Peter, Andy,
> >>a Mobile version of the Java xrootd client is available at
> >>
> >>http://www.slac.stanford.edu/~dorigoa/NetFileStream.jar
> >>
> >>(it is not an 'obfuscated' package so you can reverse-engineer it)
> >>
> >>Note 1: A Java Mobile Virtual Machine compliant with MIDP 2.0/CLDC 1.1
> >>is required in the mobile device in order to correctly run the client;
> >>AFAIK the following models support it for sure: Sony-Ericsson Z1010,
> >>Motorola A1000/E1000, *NEC e228/338/e616V.
> >>
> >>Note 2: Some device like PalmOS, WinCE compatible palm and so on, have a
> >>custom JVM unable to run MIDP applications. The free WABA JVM is unable
> >>to run NetFileStream.jar because has a completely proprietary library
> >>for socket and record database.
> >>*
> >>Note 3: The client now is only a demo: just insert the URL on the remote
> >>file (must be an ASCII and short file because its content, and its size,
> >>will be displayed on the mobile device screen) and press 'OK'. No
> >>log/error messages are displayed at the moment so you must take a look
> >>at the server log if something goes wrong.
> >>
> >>Note 4: Every Mobile device model hai its proprietary way to deploy/run
> >>the jar application into the device RAM, so I won't describe any method
> >>here. Some model has a software facility to do that very easily (only
> >>under Windows); in other models (like the old Motorola A835) the Java
> >>loader menu is HIDDEN (!), for marketing reasons (I unlocked it some
> >>time ago), I think... Google can help has usual for any problem.
> >>
> >> Alvise
> >>
> >>Peter Elmer wrote:
> >>
> >>
> >>
> >>>Hi Alvise,
> >>>
> >>>On Wed, Nov 24, 2004 at 12:26:47PM +0100, Alvise Dorigo wrote:
> >>>
> >>>
> >>>
> >>>
> >>>>Peter Elmer wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>On Wed, Nov 24, 2004 at 12:16:28PM +0100, Alvise Dorigo wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>ok, Pete. Honestly Windows is a world to test yet...
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>No problem. At least there is something to play with. (I added Tony as
> >>>>>I know he was looking at xrootd access for JAS.)
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>What's JAS ? Is Tony interested in the java client ? this is
> >>>>encouraging...
> >>>>
> >>>>
> >>>>
> >>>>
> >>>For JAS see:
> >>>
> >>>http://jas.freehep.org/
> >>>
> >>>Regarding ROOT I/O and JAS, see his talk at CHEP:
> >>>
> >>>http://indico.cern.ch/contributionDisplay.py?contribId=400&sessionId=6&confId=0
> >>>
> >>>IIRC, he had started to work on a Java client, but was aware (since I
> >>>mentioned it at CHEP) that you were working on this...
> >>>
> >>> Pete
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>>>is >~140 kB a large attach ? ok I wont do this kind attachment in
> >>>>>>future.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>Large is all relative, but in this case the limit was set low enough to
> >>>>>discourage non-trivial attachments altogether. You know how much I like
> >>>>>them.... ;-)
> >>>>>
> >>>>> Pete
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Peter Elmer wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>Hi Alvise,
> >>>>>>>
> >>>>>>>On Wed, Nov 24, 2004 at 11:14:07AM +0100, Alvise Dorigo wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>I recently fixed a number of bugs. Please use the new jar in attach
> >>>>>>>>instead of that one I sent to you some day ago. Now in the source
> >>>>>>>>and destination argument of XrdFileCopy you can omit the TCP_PORT
> >>>>>>>>number (it will try to get it from /etc/services under linux and
> >>>>>>>>from c:\\winnt\\system32\\drivers\\etc\\services under WinNT/XP,
> >>>>>>>>otherwise default=1094); in addition a 3rd parameter cab be passed
> >>>>>>>>to specify the size of copy chunk (larger chunk means more copy
> >>>>>>>>speed, default chunk size is 256 kB) so:
> >>>>>>>>
> >>>>>>>>java- jar XrdCopyFile.jar xroot://<USER>@<HOST>/SRC_PATHFILE
> >>>>>>>>xroot://<USER>@<HOST>/TARGET_PATHFILE [CHUNK_SIZE_IN_KB]
> >>>>>>>>
> >>>>>>>>Note 1: The ASYNC communication has been deeply tested with 10
> >>>>>>>>concurrent clients repeatedly reading from the same file and from
> >>>>>>>>the same server (this to put all clients on the same physical
> >>>>>>>>channel). No server-crash during reading has been triggered yet,
> >>>>>>>>but it will be done asap. The server-crash tolerance has been fully
> >>>>>>>>tested with 1 and more client in SYNC mode.
> >>>>>>>>
> >>>>>>>>Note 2: Some data corruption takes place when "oksofar" is handled,
> >>>>>>>>that means that copying files using chunks > 2MB can create data
> >>>>>>>>corruption. I'll investigate.
> >>>>>>>>
> >>>>>>>>Note 3: The Java client is supposed to run under WindowNT/XP too
> >>>>>>>>(please remember JDK1.5) but very few tests has been done: even if
> >>>>>>>>Java is fully multiplatform everybody knows that small differences
> >>>>>>>>are between platforms, versions and vedors... I developed and
> >>>>>>>>tested under Fedora Core 3 Linux (kernel 2.6.9-1.667) Sun JDK 1.5.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>Ok, thanks: I've updated the jar file linked from the xrootd page.
> >>>>>>>Very
> >>>>>>>nice that we have a windows client now, too....
> >>>>>>>
> >>>>>>>BTW, you can't send mails with large attachments to the mailing
> >>>>>>>list. It
> >>>>>>>will bounce them. (And in general sending large attachments to
> >>>>>>>mailing list
> >>>>>>>is bad practice.) You can probably just stick any future update
> >>>>>>>files someplace at SLAC and send me the location so I can put it in
> >>>>>>>the xrootd
> >>>>>>>web area...
> >>>>>>>
> >>>>>>> Pete
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>
> >>>-------------------------------------------------------------------------
> >>>Peter Elmer E-mail: [log in to unmask] Phone: +41 (22) 767-4644
> >>>Address: CERN Division PPE, Bat. 32 2C-14, CH-1211 Geneva 23, Switzerland
> >>>-------------------------------------------------------------------------
> >>>
> >>>
> >>>
> >>>
> >
> >
> >
> >-------------------------------------------------------------------------
> >Peter Elmer E-mail: [log in to unmask] Phone: +41 (22) 767-4644
> >Address: CERN Division PPE, Bat. 32 2C-14, CH-1211 Geneva 23, Switzerland
> >-------------------------------------------------------------------------
> >
> >
-------------------------------------------------------------------------
Peter Elmer E-mail: [log in to unmask] Phone: +41 (22) 767-4644
Address: CERN Division PPE, Bat. 32 2C-14, CH-1211 Geneva 23, Switzerland
-------------------------------------------------------------------------
