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. -- 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
