ERROR -- : uninitialized constant OpenSSL::SSL::SSLErrorWaitReadable (NameError)

[boazsegev]

ERROR -- : uninitialized constant OpenSSL::SSL::SSLErrorWaitReadable (NameError)

[boazsegev]

Although I wonder if the error would happen also on the development platform, you shouldn't experience the issue when deploying your application since you really shouldn't use SSL on any Heroku deployment.

Heroku's SSL is handled by Heroku's stack and your application will be invoked by Heroku's stack after decrypting the SSL data..

If you deploy your application in clear text, you will notice that both clear text and SSL are working properly.

However, if you deploy your application using SSL internally, then neither clear text nor SSL will work when deploying on Heroku...

... your clear text services will require SSL and your SSL services will require twice the SSL handshake (and experience double encryption) which isn't supported by the client side (and is a protocol error).

Try removing the SSL flags in your application and see if the deployment works properly.

[boazsegev]

P.S.

Where, in your application, are you using SSL?

[ccniuj]

I use devise to manage authentication, and I only add one line of SSL:

#/initializers/devise.rb
OpenSSL::SSL::VERIFY_PEER = OpenSSL::SSL::VERIFY_NONE if Rails.env.development?

However, removing this line did not solve this issue...

[boazsegev]

Is there a way for me to look over the code?

Here's a quick and dirty hack that might help until we resolve the matter. You can add the following to your application's:

module OpenSSL
   module SSL
       SSLErrorWaitReadable = IO::WaitReadable
   end
end
require 'openssl'

[ccniuj]

Here is the repo: https://github.com/davidjuin0519/chatty.
I did the patch and the error is gone.
But the server shut down automatically...

Here is the log:

2016-01-31T05:33:03.511541+00:00 heroku[api]: Deploy ef124d9 by [email protected]
2016-01-31T05:33:03.511541+00:00 heroku[api]: Release v24 created by [email protected]
2016-01-31T05:33:03.671152+00:00 heroku[slug-compiler]: Slug compilation started
2016-01-31T05:33:03.671162+00:00 heroku[slug-compiler]: Slug compilation finished
2016-01-31T05:33:03.609661+00:00 heroku[web.1]: State changed from up to starting
2016-01-31T05:33:05.672594+00:00 heroku[web.1]: Starting process with command `bin/rails server -p 31262 -e production`
2016-01-31T05:33:06.364868+00:00 heroku[web.1]: Stopping all processes with SIGTERM
2016-01-31T05:33:07.635965+00:00 app[web.1]: => Booting Rack
2016-01-31T05:33:07.635992+00:00 app[web.1]: => Rails 4.2.4 application starting in production on http://0.0.0.0:54779
2016-01-31T05:33:07.635993+00:00 app[web.1]: => Run `rails server -h` for more startup options
2016-01-31T05:33:07.635995+00:00 app[web.1]: => Ctrl-C to shutdown server
2016-01-31T05:33:07.635995+00:00 app[web.1]: Exiting
2016-01-31T05:33:07.635996+00:00 app[web.1]: Plezi is feeling optimistic running version 0.12.21.
2016-01-31T05:33:07.635996+00:00 app[web.1]: 
2016-01-31T05:33:07.635996+00:00 app[web.1]: Iodine 0.1.21 is listening on port 54779 with 30 thread(s).
2016-01-31T05:33:07.635997+00:00 app[web.1]: Press ^C to stop the server.
2016-01-31T05:33:07.635997+00:00 app[web.1]: 
2016-01-31T05:33:07.635998+00:00 app[web.1]: Shutting down Iodine. Setting shutdown timeout to 25 seconds.
2016-01-31T05:33:07.635999+00:00 app[web.1]: Stopped listening to port 54779.
2016-01-31T05:33:08.446666+00:00 heroku[web.1]: Process exited with status 0
2016-01-31T05:33:12.052008+00:00 heroku[web.1]: State changed from starting to up

How can I prevent this from happening? Thanks!

[boazsegev]

Hi,

I read through some of the code, not all of it, and it seems to me that there are a little too many assumptions and hacks being performed, which might produce unexpected results or raise exceptions.

for example...

    user_session = ObjectSpace.each_object(ActionDispatch::Request::Session).
      to_a.select do |session|
        session.id == cookies['_chatty_session']
      end.
      first
    # user_session might be (and probably is) `nil`, but you're not checking.
    values = user_session['warden.user.user.key']

Also, session.id refers to the Plezi session, not the Rails session.

I'm not sure why you experience the server shutting down. It doesn't happen on my machine. It could be related to the code here:

if Rails.const_defined?('API') || Rails.const_defined?('Console')
  Iodine.protocol = nil
elsif Rails.const_defined?('Server')
  # require_relative  '../app/sync/plezi_sync.rb'
end

I wonder if Heroku effects this code somehow... I would try limiting this code to the development environment. i.e.:

if ENV['RACK_ENV'] == "development" && ( Rails.const_defined?('API') || Rails.const_defined?('Console') )
  Iodine.protocol = nil
elsif Rails.const_defined?('Server')
  # require_relative  '../app/sync/plezi_sync.rb'
end

Also, you're using JSON a lot and you're moving very heavy data within every simple chat message.

This will prevent your application from being able to scale. Here are a few thoughts:

1. What will happen when you have 500 connections? Is it still possible, or effective, to collect all the connections and send their information with every chat message (even if nothing had changed)?
2. What about when you have 10,000 connections? or 100,000 connections?
3. Even if you do want to send the information about everyone connected to your website, isn't it simpler to update the data and the user only when something changes, instead of linking the data to chat messages?

I recommend, before you try mixing Plezi and Rails, that you attempt the Hello Chatroom tutorial and implement the auto_dispatch feature in an application this only Plezi.

Later, try adding events to the chat, such as private messages and maybe a chatroom counter (I would suggest using a add_chat_user and remove_chat_user events, separate from the chat message event).

It's not as easy is it might sound, because there are a lot of new concepts related to websockets, concurrency, event queues (event handling) and other new concepts that are related to the Websocket world.

After you mastered the websockets and discovered how Plezi can help you make websocket management easy (read: easier), then try to integrate Rails and Plezi together.

At that point, I would consider the best way to share user data and authentication between the two frameworks, since their session data isn't unified.

Good Luck! and let me know how it goes :-)

[ccniuj]

Hi Bo,

Thank you for your advice! I will try to follow your suggestion to accomplish my project and keep it updated with you.

I just did an experiment. I created a vary basic app test_for_plezi_deploy on heroku.
Here is the app link: http://testforplezideploy.herokuapp.com/
Here is the app repo: https://github.com/davidjuin0519/test_for_plezi_deploy
Here is where I reference from your doc wiki: https://github.com/boazsegev/plezi/wiki/Chatroom-Tutorial

I deployed to heroku without any additional setup, and the same error message still pops out: E, [2016-02-01T07:12:39.163118 #3] ERROR -- : uninitialized constant OpenSSL::SSL::SSLErrorWaitReadable (NameError). However, this app is still functioning.

So this address 2 questions for me:
1. Why is the app still functioning?
2. Can you reproduce the same error? Or this just happens on my own setting?

Thanks!

[boazsegev]

Hi david,

Before posting my answer (but after writing it), I looked over your repo.

It seems that you're still using Rails in your application... could the issue be related to Rails?

I would suggest you try to use Plezi without Rails and see if you still have this error. This way, we can isolate the error, find it and resolve it.

Thank you!

Bo.

---

old answer

I'm now working very hard on Plezi's server, Iodine, and re-writing it from it's core in C. Iodine 0.2.x is very different and the issue your experiencing seems to be related to the Iodine 0.1.21 version.

I think somewhere along the way (although I don't experience this issue), Iodine isn't requiring the openssl extension, so this error should be resolved when adding:

require 'openssl'

As to how come the application is still working - I don't know, because I can't reproduce the error... However, I did design the application to withstand many different errors without crashing. So, as long as it's not a core error, it should keep working... (although I would have thought that this error would be a core error).

When we move to Plezi 0.13.0, we will be using a totally different server (Iodine 0.2.x) which will support many more concurrent connections (Ruby's select is limited to 1024 connections and by writing in C I can support as many connections as the system's memory and capacity will allow - I tested it with 20K concurrent connections).

I'm sure that this error is limited to the Iodine 0.1.x versions.

[ccniuj]

Hi Bo,
I finally located this error.
The cause is extremely simple: I did not specify ruby version up to 2.2.3
After specifying ruby version in gemfile, it all works perfect.

Just a suggestion: Would you mind to add some reminding on the doc?

And I will continue to view the doc and source code. Thank you!

[boazsegev]

Woohooo!

Thanks!

I'm super happy it's working for you now and I'm happy you found the error - I don't think I would have discovered it, nice work.

👍🏻👍🏻👍🏻👍🏻👍🏻