In iconara/cql-rb#90 it was discovered that disconnected sockets can remain disconnected for a long time without being discovered, if the application is idle. This causes problems in cql-rb since it needs to move its event listener when a connection goes down, otherwise it won't receive UP events from the cluster.

Sockets should probably be checked on every tick in the reactor.

Ione::Future.all([]).value fails with "No live threads left. Deadlock?" instead of returning a resolved future.

Can be easily fixed by swapping the first two lines of the method.

A user running v2.1.5 of the DataStax Ruby driver encountered a 'write would block' error message when communicating with a node. We believe the underlying error is an EAGAIN or EWOULDBLOCK when attempting to write to the socket.

Looking at the ione code (v1.2.0 for C* driver 2.1.5), I don't see how we could end up with that error -- writes seem rely strictly on select returning a write-fd-set, so if the fd isn't writable, it shouldn't get a write attempt.

Nonetheless, it seems like in some cases it does get this error, so ione should catch it and drop it. Presumably a later write attempt will succeed as time elapses and the kernel buffer for the socket gradually empties.

Just make sure that this is not an issue, but it actually looks ok.

If you need to execute something on the reactor thread, or need a simple way to break long-running handlers into multiple steps it would be nice to have a way to execute something at the next reactor tick.

While it is possible to achieve the same effect with short interval timers, I think it makes sense from an API standpoint to separate the two. Also, I'm sure this can be implemented with much lower overhead.

2014-04-13 19:10:31 +0000 [error]: fluent/engine.rb:226:rescue in run: unexpected error error_class=EOFError error=#<EOFError: end of file reached>

When lots of futures are given to Future.after you can get a stack overflow error since each callback registers as a callback to the next future, and the call stack grows and grows as long as they are already resolved.

The timer handling code does linear scans and copies on timer scheduling and checking. This make it very inefficient when many timers are scheduled (e.g. when many concurrent requests are sent to Cassandra with timeouts).

Hello @iconara!

Figured this would be as good of a spot as any to ask this question, but we discovered an issue when using ione with the ruby cassandra driver and timecop. Specifically, this is the situation.

1. Configure and launch a cassandra server locally.
2. Configure an rspec suite for integration tests against the cassandra server.
3. Ensure the cassandra idle_timeout is set to the default value (60)
4. Adjust time using timecop to sometime in the future past 60 seconds.

Result:
The test will fail with a cassandra timeout error, as the scheduled ione timer for the idle_timeout has not been rescheduled, and the on_value timeout function has been called.

Given this, I could see an argument for either calling this a cassandra ruby driver issue, or a ione issue--if you'd like me to report this somewhere else, please let me know.

However, my question is: What is the best way to utilize timecop with ione?

after modifying io_reactor.rb by adding the following on line 136:

rescue => e
  puts "#{e.class.name}: #{e.message}\n" + Array(e.backtrace).join("\n")

I get the following error:

TypeError: can't convert Ione::Io::Connection to IO (Ione::Io::Connection#to_io gives NilClass)
/home/kishan/.rvm/gems/ruby-1.9.3-p547@global/gems/ione-1.2.0/lib/ione/io/io_reactor.rb:396:in `select'
/home/kishan/.rvm/gems/ruby-1.9.3-p547@global/gems/ione-1.2.0/lib/ione/io/io_reactor.rb:396:in `tick'
/home/kishan/.rvm/gems/ruby-1.9.3-p547@global/gems/ione-1.2.0/lib/ione/io/io_reactor.rb:133:in `block in start'
integration/test.rb:38:in `join': deadlock detected (fatal)
    from integration/test.rb:38:in `block in create_sessions_concurrently2'
    from integration/test.rb:38:in `each'
    from integration/test.rb:38:in `create_sessions_concurrently2'
    from integration/test.rb:15:in `run_test'
    from integration/test.rb:61:in `<main>'

The issue is that the connections are created and closed from different threads, here is a trimmed down sample that consistently fails on linux, while passing on OS X:

require 'bundler/setup'
require 'cassandra'
require 'cassandra/version'

puts Cassandra::VERSION

class Test
  def run_test
    cluster_list = []
    cluster_list << Cassandra.cluster

    session_list = create_sessions_concurrently2(cluster_list[0], 1)
    p session_list
    session_list = close_sessions_concurrently2(session_list, 1)
    p session_list

    session_list2 = create_sessions_concurrently2(cluster_list[0], 1) # DEADLOCK HERE
    p session_list2

    session_list = close_sessions_concurrently2(session_list2, 1)
    p session_list
    cluster_list[0].close
  end

  def create_sessions_concurrently2(cluster, num_sessions)
    sessions = []
    threads = (1..num_sessions).map do
      Thread.new do
        begin
          session = cluster.connect
          sessions << session
        rescue Exception => e
          # session.close
          raise RuntimeError.new("Error while creating a session. #{e.class.name}: #{e.message}
                                          Backtrace: #{e.backtrace.inspect}")
        end
      end
    end

    threads.each {|th| th.join} # DEADLOCK HERE
    sessions
  end

  def close_sessions_concurrently2(session_list, num_sessions)
    session_list2 = session_list[0...num_sessions]
    threads = session_list2.map do |session|
      Thread.new do
        begin
          session.close
          session_list.delete(session)
        rescue Exception => e
          raise RuntimeError.new("Error while closing a session. #{e.class.name}: #{e.message}
                                  Backtrace: #{e.backtrace.inspect}")
        end
      end
    end

    threads.each {|th| th.join}
    session_list
  end
end

Test.new.run_test

I believe there is a race between close and connected? that causes a closing socket to be added to the poll list.