Il giorno 11/feb/2011, alle ore 10.44, luigi scarso ha scritto: > On Tue, Feb 8, 2011 at 5:07 PM, luigi scarso <[email protected]> wrote: >> On Tue, Feb 8, 2011 at 4:29 PM, Roberto De Ioris <[email protected]> wrote: >>> >>> Il giorno 08/feb/2011, alle ore 16.19, luigi scarso ha scritto: >>> >>>> Hi, I'm pretty sure that it's a silly question, but with a POST request >>>> with >>>> content_length more than 255 >>>> I have this error on an erlang node: >>>> 'uwsgierlang@johnII' got a corrupted external term from >>>> 'uwsginode@johnII' on distribution channel 6723 >>>> >>>> Any suggestion ? >>>> >>>> >>> >>> You have reach another stupid-design-decision in the old erlang stack: >>> >>> python strings are converted to atoms (that have a very limited size). >>> >>> Try to encode the body in a list/tuple before sending to erlang. >> hm, I'm already using something like this >> uwsgi.erlang_send_message(uwsgi_erlang,'uwsgierlang@johnII', >> tuple(env.items()) ). >> I can add a key to env >> (something like env['data'] = "...very long stream of bytes ..." >> but this doesn't solve the problem, I believe. >> Or perhaps I haven't understand your answer . > Ah, ok, now I have (sorry for the noise, I'm jumping between two > differents context) > As you wrote, if length(data) > 255 bytes, then just split data in > chunks of 255 bytes. > put the chunks in a tuple and send the tuple. >
Do you want to try the new stack ? Pull from the mercurial and build with python uwsgiconfig.py --build pyerl This will build a binary with erlang and python bridge plugin embedded The new api is: erlang_connect(node) erlang_close(fd) erlang_send_message(fd or node, regname, object) [deprecated] erlang_send(fd or node, regname, object) erlang_recv_message(fd) [deprecated] erlang_recv(fd) erlang_sr(node, regname, object) erlang_rpc(fd or node, mod, fun, arg) erlang_lock() erlang_unlock() The send functions take an fd (previously created with erlang_connect) or directly the node name (the connection will be automatic). The erlang_sr function is a commodity that connect/send/receive/close (i bet you will end using this all the time). The new mapping is: erlang string -> python bytearray (string in python 2.x) erlang binary -> python bytearray (string in python 2.x) erlang int -> python int erlang float python float erlang atom -> python unicode (pay attention to this!!!) erlang list -> python list erlang tuple -> python tuple erlang pid -> mapped to python tuple of 3 elements Why mapping atom to unicode ? Because erlang strings are only syntactic sugar and under the skin maps to array of chars, and new incarnation of python make distinction between text and chars. So an erlang string is more near to a python bytearray/binarysequence and atom (as they are text with a meaning) maps better to python unicode/string. (obviously this makes no sense in python <=2.5) The server mode is still a working on so do not use it. You can use short or long names without problems: uwsgi --erlang mynode@pippo .... erlang_lock/unlock are low level functions to allow preforking mode to works without problems (you can ignore them). -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
