Como o ReactiveMongo é implementado para que seja considerado sem bloqueio?

A leitura da documentação sobre o Play Framework e o ReactiveMongo me leva a acreditar que o ReactiveMongo funciona de tal maneira que usa poucos threads e nunca bloqueia.

No entanto, parece que a comunicação do aplicativo Play com o servidor Mongo precisaria ocorrer emalgum fio em algum lugar. Como isso é implementado? Os links para o código fonte do Play, ReactiveMongo, Akka etc. também serão muito apreciados.

O Play Framework inclui alguma documentação sobre isso nesta páginasobre conjuntos de encadeamentos. Começa:

A estrutura do Play é, de baixo para cima, uma estrutura da Web assíncrona. Os fluxos são manipulados de forma assíncrona usando iterados. Pools de threads no Play são ajustados para usarmenos threads do que nas estruturas da web tradicionais, já que o IO no play-core nunca bloqueia.

Ele então fala um pouco sobre o ReactiveMongo:

O local mais comum que um aplicativo típico do Play bloqueará é quando estiver conversando com um banco de dados. Infelizmente, nenhum dos principais bancos de dados fornece drivers de banco de dados assíncronos para a JVM; portanto, para a maioria dos bancos de dados, sua única opção é usar o bloqueio de E / S. UMAUma exceção notável a isso é o ReactiveMongo, um driver para o MongoDB que usa a biblioteca Iteratee do Play para conversar com o MongoDB.

A seguir, há uma observação sobre o uso de futuros:

Observe que você pode ficar tentado a envolver seu código de bloqueio em futuros. Isso não faz com que não seja bloqueado, apenas significa que obloqueio acontecerá em um segmento diferente. Você ainda precisa se certificar de que o pool de threads que você está usando lá tenha threads suficientes para lidar com o bloqueio.

Há uma observação semelhante na documentação do Play na páginaTratamento de resultados assíncronos:

Você não pode transformar E / S síncrona em assíncrona magicamente, envolvendo-a em um futuro. Se você não pode alterar a arquitetura do aplicativo para evitar operações de bloqueio,em algum momento essa operação terá que ser executada e esse thread bloqueará. Portanto, além de incluir a operação em um futuro, é necessário configurá-la para ser executada em um contexto de execução separado, configurado com threads suficientes para lidar com a simultaneidade esperada.

A documentação parece estar dizendo que o ReactiveMongo é non-blocking, portanto você não precisa se preocupar em consumir muitos threads no seu pool de threads. Mas o ReactiveMongo precisa se comunicar com o servidor Mongoalgum lugar.

Como essa comunicação é implementada para que o Mongo não use os threads do pool de threads padrão do Play?

Mais uma vez, os links para os arquivos específicos emToque, ReactiveMongo, Akka, etc, seria muito apreciado.

questionAnswers(1)

yourAnswerToTheQuestion