gmane.comp.lang.ruby.rainbows.general

Re: Is there a good example of setting up rainbows as a comet server?

Eric Wong — 2012-05-17T00:31:20

I don't pay attention to the JavaScript side of Comet, but the
Raindrops::Watcher application uses infinite HTTP streaming.

It's running here: http://raindrops-demo.bogomips.org/

It's all packaged in the raindrops repo (zbatery is interchangeable with
rainbows in the configs here:)

  git clone git://bogomips.org/raindrops
  cd raindrops/examples/

You can run "curl http://raindrops-demo.bogomips.org/tail/0.0.0.0%3A9418.txt"
in one terminal and run the git clone above on a slow connection to
see yourself :)
_______________________________________________
Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw< at >public.gmane.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying

Re: Is there a good example of setting up rainbows as a comet server?

Brian P O'Rourke — 2012-05-17T00:11:19

You might have a look at some of the examples from Cramp:

    http://cramp.in/

I don't know much about its internals or its state of development, but
they've made an effort to make the problem approachable to someone
unfamiliar with Rainbows!

Is there a good example of setting up rainbows as a comet server?

Jason Kenney — 2012-05-16T23:51:23

Someone on stackoverflow suggested using rainbows instead of juggernaut/node.js for sending push notifications via comet.
But I can't seem to find anything about setting something up like that.

Thanks.
_______________________________________________
Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw< at >public.gmane.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying

Sveiki.

Paklausimas — 2012-05-14T09:27:20

Laba diena,

Rašome Jums iš įmonės „Internet Solutions“. Norime informuoti, kad
kuriame interneto svetaines (nemokamai), klientai moka tik už svetainės
talpinimą mūsų serveryje.
Atsinaujinusius svetainių talpinimo planus ir įkainius rasite pateiktoje
nuorodoje:
http://internetsolutions.lt/tinklapiu-kurimas
Galime susikurti svetainę ir be talpinimo paslaugos, dėl kainų
teirautis nurodytais kontaktais.

Jei jau turite svetainę, galime pasiūlyti svetainės optimizaciją (SEO
paslaugas).
Plačiau apie tai galite rasti mūsų tinklapyje:
http://internetsolutions.lt/reklama-internete/seo-paslaugos/

Taip pat galime pasiūlyti naujienlaiškių siuntimo paslaugas:
http://internetsolutions.lt/e-marketingas/naujienlaiskiu-siuntimas/

Geros dienos,




--
Evelina Navickaitė
UAB „Internet Solutions“
verslo klientų vadybininkė
+370 662 35133
sales< at >internetsolutions.lt
www.internetsolutions.lt
Reg. adresas: Tvenkinių g. 8A, Šakių k., Kauno r. sav.
Biuro - korespondencijos adresas: Lyros g. 5,

Sveiki.

Sveiki — 2012-04-12T06:29:22

Sveiki,

Prieš keletą savaičių rašėme Jums dėl interneto svetainių kūrimo
ir atnaujinimo.  Taigi norėtume dar kartą pasidomėti, galbūt
persigalvojote?
Įmonės gimtadienio proga visiems užsisakantiems 24 mėnesių svetainės
talpinimo paslaugą, taikome 3 mėnesių talpinimo nuolaidą, o visoms
kitoms paslaugoms suteikiame 10% nuolaidą  (SEO paslaugoms, reklamai
internete, naujienlaiškių siuntimui).

Nuolaidos taikomos iki 2012 m. gegužės 01 d.

Visi mūsų svetainių darbų pvz:
http://internetsolutions.lt/tinklapiu-kurimas/keletas-paskutiniu-darbu

Talpinimo įkainius rasite čia:
http://internetsolutions.lt/tinklapiu-kurimas

Naujienlaiškių darbų pvz:
http://internetsolutions.lt/e-marketingas/keletas-naujienlaiskiu-pavydziu




--
Evelina Navickaitė
UAB „Internet Solutions“
verslo klientų vadybininkė
+370 662 35133
sales< at >internetsolutions.lt
www.internetsolutions.lt
Reg. adresas: Tvenkinių g. 8A, Šakių k., Kauno r. sav.
Biuro - korespondencijos adresas: Lyros g. 5, Šiaulia

Re: 100% cpu with faye-websocket

Eric Wong — 2012-04-12T09:06:44

Have you contacted other faye users/developers on this issue?
Hopefully somebody else can help you sooner.

I'm not familiar with faye at all (this is the first I've heard of it,
even), so it'll take me some time to get up to speed.  It's been a
long while since I've looked at websockets, too.
_______________________________________________
Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw< at >public.gmane.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying

100% cpu with faye-websocket

Lion Vollnhals — 2012-04-12T08:59:55

Hi,

please CC me as i am not on the list.

i am using rainbows (configured with eventmachine) to serve faye websocket connections.
see https://github.com/faye/faye-websocket-ruby.

when the first user connects (using websocket protocol), cpu usage goes to 100% and stays there.
even when the user is idle or disconnects.

is this normal behavior?

i inspected the process using dtrace under mac os x and saw that the process is doing a lot of read and write system calls all the time.
i can observe the same 100% cpu behavior on linux. so this is not a mac os x issue.

here is my config file and command line:

# rainbows.conf
Rainbows! do
  use :EventMachine
end

rainbows config.ru -c path/to/rainbows.conf -E production -p 9292


regards,
Lion Vollnhals
_______________________________________________
Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw< at >public.gmane.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying

Re: Out of band stuff?

Damian Janowski — 2012-04-11T01:20:12

Clearly—the wrong way :)

I'm composing apps and I was doing something like:

run Rack::Builder.new { ... }

instead of:

run Rack::Builder.new { ... }.to_app

By using the latter I get consistent object_ids across requests.

Thank you and sorry for the false alarm.
_______________________________________________
Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw< at >public.gmane.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying

Re: Out of band stuff?

Eric Wong — 2012-04-10T20:37:43

Huh? How are you using Rack::Builder?  unicorn/Rainbows! should always be
using Rack::Builder#to_app instead of regenerating the Rack stack every
single request.

I've been using Raindrops::Watcher for months now, mainly with
ThreadSpawn, but ThreadPool seems to work just fine and I can confirm
neither spawns infinite aggregator threads.
_______________________________________________
Rainbows! mailing list - rainbows-talk< at >rubyforge.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying

Re: Out of band stuff?

Eric Wong — 2012-04-10T20:16:38

You are correct :)
_______________________________________________
Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw< at >public.gmane.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying

Re: Out of band stuff?

Damian Janowski — 2012-04-10T20:24:56

One more question. Can you confirm that this technique doesn't work as
expected using Rainbows/ThreadPool? I've found that Rack::Builder
creates a new instance of each middleware on every request, so you'd
end up spawning infinite aggregator threads.
_______________________________________________
Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw< at >public.gmane.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying

Re: Out of band stuff?

Damian Janowski — 2012-04-09T13:04:26

Great, that should get me started!


By the way, why does #aggregator_thread call #wait_snapshot before
returning the thread? (I'm no expert in threading, but my guess is to
wait for the first loop to run correctly?)
_______________________________________________
Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw< at >public.gmane.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying

Re: Out of band stuff?

Eric Wong — 2012-04-09T03:05:52

For Raindrops::Watcher, I start a background thread on the first request:

git clone git://bogomips.org/raindrops.git
$EDITOR lib/raindrops/watcher.rb

If you look at the `call' method in raindrops/watcher.rb, the important
line is this:

# < at >start is a Mutex and < at >thr is nil in the initialize method.

< at >start.synchronize { < at >thr ||= aggregator_thread(env["rack.logger"]) }

I avoid starting the background thread at initialization because it'll
die on fork (meaning I'd have to recheck it all the time, anyways).

The overhead of Mutex#synchronize and < at >thr||= assignment is negligible
in most apps.


Yes, Unicorn::OobGC is very specific to how Unicorn works and the way it
works wouldn't translate well to Rainbows! (as Rainbows! does persistent
connections and unicorn does not).
_______________________________________________
Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw< at >public.gmane.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when r

Out of band stuff?

Damian Janowski — 2012-04-06T21:49:34

Hello everyone,

I'm needing to perform a couple of tasks outside of the request cycle.
For instance, I want to ping a web service every X minutes so that I
can maintain a persistent connection to it and have better response
times for some requests that I have to do *inside* the request cycle.

What would be the reasonable way of doing this?

I'm thinking the OOB GC is just another example. But the current way
the OOB GC is written makes one think it's a very specific case and
not something one should use for other purposes.

Thoughts?

Thanks in advance.

D.
_______________________________________________
Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw< at >public.gmane.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying

Re: 'Connection reset by peer' when replying before the end of POSTdata

Eric Wong — 2012-03-02T21:05:14

Ouch :(

I think using 100-continue is the only halfway-viable choice.
Too bad it's:

  1) subject to race conditions
  2) can't help with chunked transfers
  3) not widely-supported (any widespread clients besides curl?)

Anyways, thanks for all your testing and reports!
_______________________________________________
Rainbows! mailing list - rainbows-talk< at >rubyforge.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying

Re: 'Connection reset by peer' when replying before the end ofPOST data

Lunar — 2012-03-02T16:29:42

Just for the record, reverse proxying this last iteration with Nginx
(with "proxy_buffering off;") or Apache (with
"SetEnv proxy-sendchunks 1") result in 413 displayed and full
transmission of the given file with all clients (curl included).

Re: 'Connection reset by peer' when replying before the end ofPOST data

Lunar — 2012-03-02T16:03:53

Actually, they don't, I was a little too quick to answer. I made some
more test, sending a 8.1 MB file over a Wi-Fi connection between two
systems. For each test, I created a pcap file by recording the HTTP
transmission.

curl is 7.21.2-4, and I am using:

    curl -v -F "file=< at >test-file.xcf;type=application/x-xcf" \
            -F "submit=submit" http://webserver/

epiphany is 2.30.6-1, using WebKit and IIRC, libsoup for its HTTP
connections. Iceweasel is version 3.5.16-12. w3m is 0.5.2-10. All coming
from Debian Squeeze.

Here's what's hapenning for nginx (0.7.67-3+squeeze1) when
`client_max_body` is set to `1m`:

  - curl: 413 displayed, 9.5K
  - w3m: 413 displayed, 8.8M
  - iceweasel: 413 displayed, 8.8M
  - epiphany: 413 displayed, 8.8M

For Apache (2.2.16-6+squeeze6), using `LimitRequestBody 1048576`:

  - curl: 413 displayed, 1.8K
  - w3m: 413 displayed, 8.8M
  - iceweasel: 413 displayed, 8.9M
  - epiphany: 413 displayed, 8.8M

So it looks usual HTTP web server and clients will drain all the POST
inp

Re: 'Connection reset by peer' when replying before the end ofPOST data

Eric Wong — 2012-02-29T21:36:01

Cool, thanks for confirming.  It's good that your client knows to back
off.  My original patch isn't safe for bad clients that send
continously.  Below is a safer version of my original patch, can you
see if it works?

diff --git a/lib/rainbows/client.rb b/lib/rainbows/client.rb
index b456eca..1dcb6d4 100644
--- a/lib/rainbows/client.rb
+++ b/lib/rainbows/client.rb
< at >< at > -6,4 +6,16 < at >< at > class Rainbows::Client < Kgio::Socket
   include Rainbows::ProcessClient
 
   alias write kgio_write
+
+  def close
+    close_write
+    kgio_wait_readable(2)
+    buf = ""
+    case kgio_tryread(512, buf)
+    when nil, Symbol
+      break
+    end while true
+    ensure
+      super
+  end
 end


I'll probably call it "lingering_close" like nginx calls it.  Of course
this needs to be supported for EM/Cool.io, too.
_______________________________________________
Rainbows! mailing list - rainbows-talk< at >rubyforge.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replyi

Re: 'Connection reset by peer' when replying before the end ofPOST data

Lunar — 2012-02-29T20:57:58

With your proposed patch, everything is working as intended. At least, I
can confirm Firefox correctly display the error message sent by the
server and not the less understandable "Connection reset by peer". I can
also confirm that it does not send the complete file: it looks like it
stops sending as soon as either it notices the socket is closed on its
write part, or when the response arrives. I am satisfied enough not to
dive in libxpcom…


That was exactly what I was looking for. It even works fine on Ruby
1.8.7. I can include that code directly in Coquelicot (by reopening
Rainbows::Client to add this extra method) so my pet case is solved.

I could see it part of Rainbows!, as optional behaviour, off by default
if you'd prefer, but I am fine either way.

Thanks for your help! I will let you know as soon as enhanced Coquelicot
codebase using Rainbows! is clean enough for a wider exposure (and I
have been noticed that the public repository is now back).

Cheers,

Re: 'Connection reset by peer' when replying before the end ofPOST data

Eric Wong — 2012-02-29T17:23:15

It's very expensive to do what Apache does with threads+Rainbows!.  It
also appears that Apache and nginx continues to completely drain the
socket if the client is sending, too (which is your case).

I don't know if there's a way around draining the socket entirely to
avoid connection resets in the client :<

I'm more interested in keeping good clients going and not wasting server
resources dealing with clients I don't want in the first place.


There's a shutdown method in BasicSocket for 1.8


You could emulate lingering close with something like this:
(valid for ThreadSpawn/ThreadPool, not EM/Cool.io stuff)

diff --git a/lib/rainbows/client.rb b/lib/rainbows/client.rb
index b456eca..9d8256a 100644
--- a/lib/rainbows/client.rb
+++ b/lib/rainbows/client.rb
< at >< at > -6,4 +6,16 < at >< at > class Rainbows::Client < Kgio::Socket
   include Rainbows::ProcessClient
 
   alias write kgio_write
+
+  def close
+    close_write
+    buf = ""
+    begin
+      kgio_wait_readable(2)
+      buf = kgio_tryread(512, buf)
+    rescue
+

Re: 'Connection reset by peer' when replying before the end ofPOST data

Lunar — 2012-02-29T07:22:34

Hi Eric,

Thanks for your quick answer!

Eric Wong wrote:

I thought about it, but I would rather not do that. Coquelicot is meant
as a small, self-contained application that can also be run at home
behind broadband connections with small bandwidth or quota. If users set
a file limit of 5 MiB, I would rather not drain the whole 700 MiB before
denying the request.
 

Quoting the "HTTP Connection Management" document [1] which I mentioned
previously: "Servers must therefore close each half of the connection
independently."

After digging some more at Nginx, it looks like Nginx is doing exactly
that. I also looked at Apache and the code responsible for half-closing
both side of the connection is very readable. Function is called
`ap_lingering_close()` in server/connection.c.

It looks like there is no way to call shutdown(2) in Ruby 1.8.7, but
from the documentation, Ruby 1.9.3 has IO#close_read and IO#close_write
method that will call shutdown(2) for each half of a socket.

I don't have Ruby 1.9.3 right now,