openerp-india team mailing list archive

["Olivier Dony \(OpenERP\)" <1077985@xxxxxxxxxxxxxxxxxx>]

Hi Kyle,

Please allow me to elaborate on Amit's comment.

Even if the HTTP/TCP protocols stacks that OpenERP uses provided an easy
way to do this (which they don't, most of the time an HTTP server will
only notice that the client is gone when it sends back the HTTP answer,
and fails), wouldn't it be more sensible to simply make the software
scale better?

What you're saying here is that OpenERP is sensitive to a denial of
service problem if several users start expensive operations at the same
time and then cancel them. Well, consider the case where they *don't*
cancel them, and therefore expect an answer? Shouldn't that just work?
Those extra "cancelled requests" that the server may sometimes need to
handle could easily be real requests from a little bit more users, and
we would need the server to properly answer, as there would be no
escape.

This is really a question of architecture, not just about saving a few
CPU cycles in certain cases (like dropped requests).

There will always be operations that are more expensive than others, and
there will always be cases where there are more users than expected. We
should design OpenERP in a way that allows it to scale no matter what.
That's why 6.1 introduced true statelessness and multi-process
capabilities in the server: so you can run as many OpenERP servers as
you want in parallel, letting you scale as needed. And the multi-process
mode lets you put CPU and memory limits on each on those processes, to
guarantee that a single request can never bring the service down. In
OpenERP 7.0 and later we'll further improve these capabilities in order
to squeeze even more performance out of the same hardware, thanks to
this design.

So if users often start expensive requests without waiting for the
answer, just size your deployment as if there were a bit more users, it
will happen someday anyway.

And what about malicious users that would try to bring the service down with a lot of expensive requests on purpose?
Well, first of all, it would be trivial for them to keep the connections open until the server answers, so detecting dropped connections is irrelevant. Secondly, Denial of Service attacks don't need expensive requests, they simply flood the target with small requests until something gets overloaded: the database, the memory, the CPU, the network link... whatever it is that saturates first, there's always a limit when someone really means it.

Don't get me wrong, I'm not saying that OpenERP is super fast in all
areas, there's certainly room for improvement. But I think we should
improve those parts to provide a better user experience, not as a way to
prevent system overload.

Thanks,

** Changed in: openobject-server
       Status: Opinion => Won't Fix

-- 
You received this bug notification because you are a member of OpenERP
Indian Team, which is subscribed to OpenERP Server.
https://bugs.launchpad.net/bugs/1077985

Title:
  Connection not released after browser close

Status in OpenERP Server:
  Won't Fix

Bug description:
  In the web client, I go to the product normal form. By default it
  loads 80 records. Takes only a few seconds. I can change the filter to
  show unlimited. This generation takes significantly longer because the
  application tries to compute the stock for each product. The more
  stock moves you have the longer it takes. Sometimes this operation can
  take more than 1 minute. During this load time, if I decide to close
  my browser the query will continue to execute server side. It only
  stops when it is completed. I could perform this operation with
  several browser windows until the system is deadlocked and out of
  shared memory. This is a major design flaw.

  
  If I close my browser, it should immediately terminate the connection executing server side. Any type of long running operation will compound to this problem. Especially if the user becomes impatient, closes the window and opens a new window for a second attempt.

To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-server/+bug/1077985/+subscriptions