HI Hieu The change to regular moses will be minimal. Instead of an abort(), there will be an uncaught exception, which will lead to a call to abort(). So we don't have to worry about leaks etc (moses will exit) and it will be clear to the user that the translation failed.
For server moses, I agree that there could be problems. Stack unwinding may not free all resources (ie memory) since we don't use raii everwhere. Informing the user should be straight forward - xmlrpc should have some mechanism for indicating that the operation failed, cheers Barry On Wednesday 30 September 2009 22:07:09 Hieu Hoang wrote: > i've been told performance isn't an issue anymore but i suppose we > should double check before we go down this route > > the main thing is to cleanup up after an exception to make sure there > are no leaks etc, and to have some kind of feedback/logging so that the > user can re-attempt the translation. > > its more fiddly than you think > > Barry Haddow wrote: > > Hi Hieu > > > > At the moment moses calls abort() if it receives invalid xml. It would be > > easy to change this to throw a runtime_error(), which would normally just > > lead to an abort() call as the exception wouldn't be caught. However I > > could arrange for the moses server to catch the exception and send some > > error message back to the client. > > > > There used to be concerns about portability and performance which made be > > reluctant to use exceptions. Surely these are not still valid? Are there > > any other good reasons for not using an exception in this case? > > > > cheers > > Barry > > > > On Wednesday 30 September 2009 15:56, Hieu Hoang wrote: > >> there has been talk of using exceptions to catch errors such as input > >> format but, so far, no-one's taking the lead on this yet > >> > >> 2009/9/30 Barry Haddow <[email protected]> > >> > >>> Hi Bernd > >>> > >>> Responses inline. > >>> > >>>> Then I tried to compile moses server. > >>>> It went wrong on a 64bit machine while compiling the prerequisite > >>> > >>> xmlrpc-c: > >>>> make[2]: Entering directory `/usr/src/xmlrpc-c-1.06.37/src/cpp' > >>>> g++ -shared -Wl,-soname,libxmlrpc_cpp.so.3 -o libxmlrpc_cpp.so.3.06 > >>>> XmlRpcCpp.o /usr/bin/ld: XmlRpcCpp.o: relocation R_X86_64_32 against > >>>> `a local symbol' can not be used when making a shared object; > >>>> recompile with -fPIC XmlRpcCpp.o: could not read symbols: Bad value > >>>> collect2: ld returned 1 exit status > >>>> make[2]: *** [libxmlrpc_cpp.so.3.06] Error 1 > >>>> > >>>> No idea what is going wrong here. I did "make clean" and tried it > >>>> again with "-fPIC", but it did not solve the problem. The author of > >>>> this > >>> > >>> library > >>> > >>>> did not answer to my question. > >>> > >>> I've successfully compiled xmlrpc-c on a 64 bit machine, running SuSe11 > >>> and g++ 4.3.1. I'm using the latest stable release of xmlrpc-c, which > >>> its version.h reports as 1.16.19. > >>> > >>>> Then I compiled mosesserver on a 32bit machine and everything went > >>>> fine. > >>> > >>> It > >>> > >>>> is running and responding. The first answer takes about 5 seconds, the > >>>> following are very fast (about 0.05 seconds). > >>> > >>> The first sentence takes longer because it lazy-loads the vocabulary > >>> table. I > >>> have a small script which sends an initial sentence to each of our > >>> servers to > >>> make sure they're fully loaded. Maybe there's a better design choice? > >>> > >>>> I started it in the following way: > >>>> nohup mosesserver -f /opt/data/moses/ini/moses_de-en_srilm.ini > >>> > >>> -xml-input > >>> > >>>> exclusive --server-port 8080 --server-log > >>>> /opt/data/moses/logs/de-en.log.txt & > >>>> > >>>> The only problem is still invalid xml input. > >>>> When I sent "bla <tag1>blubb</tag2>" it just dies without any notice. > >>> > >>> Moses tends to crash when it doesn't like the input, which isn't what > >>> you want > >>> in a server. I should update the server so it catches and logs any > >>> exceptions > >>> that moses throws, and then continues serving requests. > >>> > >>>> How can I prevent this? > >>>> > >>>> Is there a way to create a auto respawn server? > >>> > >>> You can use inittab to do this. However before going down this road, > >>> the moses > >>> server could certainly be made more robust. I found that some of our > >>> servers > >>> crashed because of excessively long input (6000+ character sentences), > >>> so we > >>> should truncate long sentences. Invalid xml also causes a crash, as you > >>> have > >>> observed. Any other data on what causes the server to crash would > >>> definitely > >>> be useful, > >>> > >>> thanks for your feedback, > >>> > >>> regards > >>> Barry > >>> > >>> > >>> > >>> _______________________________________________ > >>> Moses-support mailing list > >>> [email protected] > >>> http://mailman.mit.edu/mailman/listinfo/moses-support > >>> > >>> > >>> -- > >>> The University of Edinburgh is a charitable body, registered in > >>> Scotland, with registration number SC005336. _______________________________________________ Moses-support mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/moses-support
