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
