Add post

Author: Coderik

_posts/2016-08-28-telegram-bot-voice-messages.md

@@ -4,7 +4,7 @@ title:  "Voice messages with python-telegram-bot"
 date:   2016-08-28 11:10:00 +0200
 categories: telegram python
 ---
-Recently I was playing around with the Telegram's Bot API using the [python-telegram-bot](https://github.com/python-telegram-bot/python-telegram-bot) library. I have faced a small but curious issue. Let's say that we want to sent an mp3 file to a Telegram chat. We have two options here: either send the file as a voice message or as a general file. In the first case the audio should be playable right through any Telegram client, while in the second case a user should be able to download it. With python-telegram-bot this can be done via methods Bot.sendVoice and Bot.sendDocument.
+Recently I was playing around with the Telegram's Bot API using the [python-telegram-bot](https://github.com/python-telegram-bot/python-telegram-bot) library. I have faced a small but curious issue. Let's say that we want to send an mp3 file to a Telegram chat. We have two options here: either send the file as a voice message or as a general file. In the first case the audio should be playable right through any Telegram client, while in the second case a user should be able to download it. With python-telegram-bot this can be done via methods Bot.sendVoice and Bot.sendDocument.
 
 By the way, for the web client both options seem to be equal at a first sight: a user has *Download* and *Play* links in either case. However, when we send an audio as a voice message, it gets wrapped in the mpeg container, and that is what our user downloads.
 
@@ -153,3 +153,5 @@ song_filename = somehow_extract_name_from_url(song_url)
 voice = BufferWithName(song_response.content, song_filename)
 bot.sendVoice(chat_id, voice=voice)
 {% endhighlight %}
+
+Another option would be to wrap BytesIO in io.BufferedReader which has *name* attribute. 

_posts/2016-09-04-ssl-problem-in-multiprocess-uwsgi.md

@@ -0,0 +1,44 @@
+---
+layout: post
+title:  "SSL problem in multiprocess uWSGI app"
+date:   2016-09-04 17:31:00 +0200
+categories: uwsgi
+---
+I have encountered a tricky issue while playing with [python-telegram-bot](https://github.com/python-telegram-bot/python-telegram-bot) library. A clear sign of the issue is the following exception appearing from time to time when we send a message to Telegram via python-telegram-bot:
+
+{% highlight Bash %}
+urllib3 HTTPError [Errno 1] _ssl.c:1429: error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac
+{% endhighlight %}
+
+Well, actually the issue has nothing to do with python-telegram-bot library itself, but is rather related to the implementation of OpenSSL in Debian. The problem appears when *the same* SSL connection is used in two concurrent processes. As always with concurrency-related issues, everything might work correctly for a while, then break suddenly and mysteriously, and then continue to work for another hundreds of trials. Leaving the deep internals of SSl aside, let's see how it affects a telegram bot.
+
+<!--more-->
+
+Commonly uWSGI is configured to spawn multiple working processes to serve requests. Every process runs its own instance of our Flask application. What causes the problem is the way uWSGI spawns these processes by default. It initializes an application only once and then copies it to several working processes. This saves some memory, but unfortunately is not appropriate in our case. Most likely in our bot application we create telegram.Bot object only once - on initialization - and end up with the same instance in all the processes. Shared telegram.Bot object means shared SSL connection.
+
+In order to change the default behavior we should set *lazy-apps* option in uWSGI config. Note that there is another option called *lazy*, but its usage is strongly discouraged in the [doc](http://uwsgi-docs.readthedocs.io/en/latest/ThingsToKnow.html).
+
+To sum it up, the uWSGI config *your-app-name.ini* might look somewhat like this:
+
+{% highlight Bash %}
+[uwsgi]
+module = <FILE:CALLABLE>
+
+master = true
+processes = 2
+
+socket = <SOCKET>
+chmod-socket = 666
+vacuum = true
+
+# Fix 'ssl+multiprocessing' issue
+lazy-apps = true
+
+die-on-term = true
+{% endhighlight %}
+
+### Relevant references:
+* [Issue in "requests" lib's tracker](https://github.com/kennethreitz/requests/issues/1906)
+* [Stackoverflow](http://stackoverflow.com/questions/3724900/python-ssl-problem-with-multiprocessing)
+* [Stackoverflow](http://stackoverflow.com/questions/22752521/uwsgi-flask-sqlalchemy-and-postgres-ssl-error-decryption-failed-or-bad-reco)
+