Mongrel as service....odd

Here comes more useful info.

Using mongrel’s direct link, instead of routing through lighttpd gives
me about a 1 in 7 or 8 (same amount) of popping up with an error 500.
It makes very little sense to me because I know lighttpd routed properly
(had it not, I’d never have seen a rails error).

Confusion still there…

Hmm…I ran another stress run (20 pages at once) and the login screen
gave me a 500 error once as well… Something’s up…I don’t think one
mongrel can handle 20 connections, but since the failure rate goes -way-
up when I have a database involved, I’m uncertain…

C.jay Martin wrote:

Can’t totally rule out Mongrel routing, because the test was so simple
and I was unable to enforce two simultaneous attempts, but the hello
program, loaded on over 20 panes simultaneously, had zero errors…

Second-check. I did the same exact thing with the login screen for the
real program (it doesn’t link to the database…that’s -IT- for
differences) and not one error. It has to be DB related.

I think all that leaves is the DB, Rails’ link to the database, or
Mongrel’s treatment of the processes in regards to the DB. It’s
definitely related to the DB though.

Luis L. wrote:

On 2/26/07, C.jay Martin [email protected] wrote:

with me having to push it with simultaneous connections. Either
something is drastically wrong with mongrel’s concurrency capabilities,
or something’s up with SQL Server. At this point, I’m pretty convinced
there’s nothing in my code or NTFS permissions doing this.

NTFS Permissions update:

Tossed the whole thing onto a test box, gave ruby, my app, mongrel, etc
full user permissions. Still seems to happen.

You still use the SQL Server as backend, right?

Could you try a clean rails app as service? put some test controller
(like hello world action).

If that don’t fail, is related to our SQL Server connection that
timeout and raise some issues (randomly it seems).


Luis L.
Multimedia systems

Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

On 2/26/07, C.jay Martin [email protected] wrote:

DBA just got back to me. The user logging in to the table has no
connection limit. That means it has to be either the ADO.rb linking to
SQL Server, or Mongrel’s handling of the database…Or unhandled
timeouts…

Most usual are unhandled timeouts. Mongrel CAN serve 20+ request, but
not with Rails, since isn’t Thread-Safe and require a big lock around
it to avoid random and madness due ActiveRecord:

http://mongrel.rubyforge.org/docs/frameworks.html

Also pointed in the FAQs:

http://mongrel.rubyforge.org/faq.html

How would I go about making a timeout infinite, or handling one?
This is an enterprise grade Database on a server that doesn’t get hit
hard… I really don’t see why it’d be timeouts, honestly…but I’ll
keep the possibility in mind.

Previously you was serving your rails applications with lighttpd and
fastcgi, right? That means a bunch of ruby process to “balance” the
load of every request that get into lighty.

Since you’re running one instance (as service), several hits to the
same instance will timeout, mostly due slow answers from DB (most of
the cases).

Could someone contribute more with SQL Server setups? I’m not a user
of them, could try to re-create Jays scenario but will take time.


Luis L.
Multimedia systems

Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

DBA just got back to me. The user logging in to the table has no
connection limit. That means it has to be either the ADO.rb linking to
SQL Server, or Mongrel’s handling of the database…Or unhandled
timeouts…

How would I go about making a timeout infinite, or handling one?
This is an enterprise grade Database on a server that doesn’t get hit
hard… I really don’t see why it’d be timeouts, honestly…but I’ll
keep the possibility in mind.

C.jay Martin wrote:

Can’t totally rule out Mongrel routing, because the test was so simple
and I was unable to enforce two simultaneous attempts, but the hello
program, loaded on over 20 panes simultaneously, had zero errors…

Second-check. I did the same exact thing with the login screen for the
real program (it doesn’t link to the database…that’s -IT- for
differences) and not one error. It has to be DB related.

I think all that leaves is the DB, Rails’ link to the database, or
Mongrel’s treatment of the processes in regards to the DB. It’s
definitely related to the DB though.

Luis L. wrote:

On 2/26/07, C.jay Martin [email protected] wrote:

with me having to push it with simultaneous connections. Either
something is drastically wrong with mongrel’s concurrency capabilities,
or something’s up with SQL Server. At this point, I’m pretty convinced
there’s nothing in my code or NTFS permissions doing this.

NTFS Permissions update:

Tossed the whole thing onto a test box, gave ruby, my app, mongrel, etc
full user permissions. Still seems to happen.

You still use the SQL Server as backend, right?

Could you try a clean rails app as service? put some test controller
(like hello world action).

If that don’t fail, is related to our SQL Server connection that
timeout and raise some issues (randomly it seems).


Luis L.
Multimedia systems

Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

Previously, it was Webrick for me… I expected to have access to apache
with fastcgi when I was developing the project… apparently only
certain purchased apps are allowed to use the apache server… so the
webserver guy gave me the admin pass to the webserver and said “get your
rails app working here”.

I think I’m going to try lighttpd with fastcgi instead, honestly…
It’ll mean another midnight, but if I can’t get mongrel working…bleh

Luis L. wrote:

On 2/26/07, C.jay Martin [email protected] wrote:

DBA just got back to me. The user logging in to the table has no
connection limit. That means it has to be either the ADO.rb linking to
SQL Server, or Mongrel’s handling of the database…Or unhandled
timeouts…

Most usual are unhandled timeouts. Mongrel CAN serve 20+ request, but
not with Rails, since isn’t Thread-Safe and require a big lock around
it to avoid random and madness due ActiveRecord:

http://mongrel.rubyforge.org/docs/frameworks.html

Also pointed in the FAQs:

http://mongrel.rubyforge.org/faq.html

How would I go about making a timeout infinite, or handling one?
This is an enterprise grade Database on a server that doesn’t get hit
hard… I really don’t see why it’d be timeouts, honestly…but I’ll
keep the possibility in mind.

Previously you was serving your rails applications with lighttpd and
fastcgi, right? That means a bunch of ruby process to “balance” the
load of every request that get into lighty.

Since you’re running one instance (as service), several hits to the
same instance will timeout, mostly due slow answers from DB (most of
the cases).

Could someone contribute more with SQL Server setups? I’m not a user
of them, could try to re-create Jays scenario but will take time.


Luis L.
Multimedia systems

Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

Eh…I had to rewrite all the Rails sql statements on the swap, but
otherwise, SQL was fine till I swapped to mongrel as a service.

My opinions/decisions bear very little weight upon IT, sadly, but any
solution I can confirm and prove, will probably be accepted if I spin it
as “still using only one system as a webserver”… long story…I think
I’m going to try to use lighttpd with fastcgi instead… we’ll see what
happens

Luis L. wrote:

On 2/27/07, C.jay Martin [email protected] wrote:

Previously, it was Webrick for me… I expected to have access to apache
with fastcgi when I was developing the project… apparently only
certain purchased apps are allowed to use the apache server… so the
webserver guy gave me the admin pass to the webserver and said “get your
rails app working here”.

I think I’m going to try lighttpd with fastcgi instead, honestly…
It’ll mean another midnight, but if I can’t get mongrel working…bleh

I don’t know how SQL Server from *nix will for for you, but deploying
isn’t a thing so simple that “you drop a file here and you’re ready to
roll”.

It requires a lot of thinking and often a re-thinking based on the
initial results. Often it takes me 3 rounds to get a good deployment
environment, without counting DB communication issues.

Guess Zed will agree with me on this: If your company is “constrained”
to windows environment (that includes IIS), you should find a
workaround… hey, you could even add pen [1] to the equation and do
some load balancing to a bunch of mongrel via ISAPI rewrite:

IIS → ISAPI rewrite → Pen (cygwin) → Bunch of Mongrels.

If your decisions have height at your company, use a scenario that
makes you feel better, nothing stops you, all we want is that you be
happy :slight_smile:

Your questions are welcome, but ignoring issues regarding DB<->App
communication (I guess since you’re running just one instance of your
application) isn’t right.

There are things inherent to each solution that you must know (or at
least try), even if you coded your app in a “magical” framework like
rails.

I’m here to contribute and help the community, so feel free to ask :slight_smile:


Luis L.
Multimedia systems

Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

Sorry, forgot to log in. That last message was me

On 2/27/07, C.jay Martin [email protected] wrote:

Previously, it was Webrick for me… I expected to have access to apache
with fastcgi when I was developing the project… apparently only
certain purchased apps are allowed to use the apache server… so the
webserver guy gave me the admin pass to the webserver and said “get your
rails app working here”.

I think I’m going to try lighttpd with fastcgi instead, honestly…
It’ll mean another midnight, but if I can’t get mongrel working…bleh

I don’t know how SQL Server from *nix will for for you, but deploying
isn’t a thing so simple that “you drop a file here and you’re ready to
roll”.

It requires a lot of thinking and often a re-thinking based on the
initial results. Often it takes me 3 rounds to get a good deployment
environment, without counting DB communication issues.

Guess Zed will agree with me on this: If your company is “constrained”
to windows environment (that includes IIS), you should find a
workaround… hey, you could even add pen [1] to the equation and do
some load balancing to a bunch of mongrel via ISAPI rewrite:

IIS → ISAPI rewrite → Pen (cygwin) → Bunch of Mongrels.

If your decisions have height at your company, use a scenario that
makes you feel better, nothing stops you, all we want is that you be
happy :slight_smile:

Your questions are welcome, but ignoring issues regarding DB<->App
communication (I guess since you’re running just one instance of your
application) isn’t right.

There are things inherent to each solution that you must know (or at
least try), even if you coded your app in a “magical” framework like
rails.

I’m here to contribute and help the community, so feel free to ask :slight_smile:


Luis L.
Multimedia systems

Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

On 4/10/07, Kevin A. [email protected] wrote:

c:/ruby/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/dependencies.rb:249:in

`paginator_and_collection_for’
xml = Builder::XmlMarkup.new

Kevin,

What you describe sounds like a pre-0.3.1 version of mongrel_service.

Also, write operations (since guess you’re creating a file) will be
affected by Access Control List on Windows (most of the times known as
Permissions and LUA bugs).

Have you tried latest version? (0.3.1)

Anyway, space issues are odd, but found since started with ruby on
windows that tabs, carrier returns (\r) and new lines (\n) in models,
controllers and worse on views produce a lot of weirdness around your
applications (and most of the times impossible to trace or debug).


Luis L.
Multimedia systems

Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

I had a similar problem using Mongrel as a service. Application worked
fine when run from the command line, but stopped working when I switched
it over to a service. Below is the error I was receiving:

Processing DesignController#entity_operations (for 10.5.5.34 at
2007-04-10 11:12:25) [POST]
Session ID: 2a296cf41d598819d3271119c7ef2c74
Parameters: {“action”=>“entity_operations”, “id”=>“34”,
“controller”=>“design”, “sort”=>“name”}

Errno::EINVAL (Invalid argument):
/app/models/operation.rb:166:in `write’

The next time I attempted to call the “entity_operations” method I would
get a totally different error which was:

LoadError (Expected
c:/web/cincom_design/config/…/app/models/operation.rb to define
Operation):
c:/ruby/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/dependencies.rb:249:in
load_missing_constant' c:/ruby/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/dependencies.rb:452:inconst_missing’
c:/ruby/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/dependencies.rb:464:in
const_missing' c:/ruby/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/inflector.rb:250:inconstantize’
c:/ruby/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/core_ext/string/inflections.rb:148:in
constantize' c:/ruby/lib/ruby/gems/1.8/gems/actionpack-1.13.3/lib/action_controller/pagination.rb:195:inpaginator_and_collection_for’
c:/ruby/lib/ruby/gems/1.8/gems/actionpack-1.13.3/lib/action_controller/pagination.rb:130:in
paginate' /app/controllers/design_controller.rb:351:inentity_operations’

It has taken me several hours to resolve this, but finally figured out
that this error was being caused by a “space” in the model file between
a method name and the left “(” of the parameter listing. Specifically, I
was using a Builder::XmlMarkup variable calling the “Row” and “Cell”
methods as shown below:

xml = Builder::XmlMarkup.new
xml.Row ("ss:Height" => "64.5", "ss:StyleID" => "s23") {
      xml.Cell ("ss:StyleID" => "s22") {
        xml.Data("Entity Name", "ss:Type" => "String")
      }

As soon as I removed all the spaces between the method and parameter
list, the application began to work.

Don’t know if this helps anyone else, but I thought it may be useful to
someone.

Kevin

Yeah…final update… I nixed Mongrel and used apache/fcgi, everything
works perfectly, and significantly faster than 4 mongrel processes (the
number I found worked fastest in the first place)

Luis L. wrote:

On 4/10/07, Kevin A. [email protected] wrote:

c:/ruby/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support/dependencies.rb:249:in

`paginator_and_collection_for’
xml = Builder::XmlMarkup.new

Kevin,

What you describe sounds like a pre-0.3.1 version of mongrel_service.

Also, write operations (since guess you’re creating a file) will be
affected by Access Control List on Windows (most of the times known as
Permissions and LUA bugs).

Have you tried latest version? (0.3.1)

Anyway, space issues are odd, but found since started with ruby on
windows that tabs, carrier returns (\r) and new lines (\n) in models,
controllers and worse on views produce a lot of weirdness around your
applications (and most of the times impossible to trace or debug).


Luis L.
Multimedia systems

Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi