On Wed, 2010-04-28 at 11:58 -0400, Nair, Arjun (Arjun) wrote: > > - http://track.sipfoundry.org/browse/XX-8298 SipXsupervisor seg-faults > when transferring large files ( > 21MB) through File.replace XML-RPC > > - We will need to add additional support in the File.replace API to > support uploading audio files, namely, the ability to declare a > directory as a process resource, and being able to write an arbitrary > number of files into this directory. As far as I can tell, we > currently don't support this.
Yes, we do. http://track.sipfoundry.org/browse/XX-7259 The process definition must have a 'directory' resource, containing a 'path' element with the directory path, and one or more 'filePattern' elements defining the file name patterns allowed. See sipXsupervisor/meta/sipXecs-process.xsd.in > - From the code it looks like we read the entire file contents into > memory before writing it out. IMO, A "streaming" model would be more > appropriate here, esp. w.r.t. large files. Yes, that part is true, and with XML RPC that's unavoidable. That was my main rationale for suggesting the addition of PUT support in the supervisor. You've established that 21 MB is somewhere above the upper bound of useful sizes... > >From sipXconfig side: > > - I would prefer to do a high level fix (maybe at the AssetSelector > class) which will carry out all file manipulations through > sipXsupervisior. This would be a fairly engaging task, but it will > de-couple a lot of services from being "co-resident" with sipXconfig. > > Based on these, I think XX-8242 is a 4.3 candidate. If that's what we decide (and I agree), then we should fix the role constraints accordingly. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
