San Ji,
We use the former because it is easier to configure and also works in dev
and test environments without nginx.
On Saturday, August 10, 2019 at 11:56:21 PM UTC-5, San Ji wrote:
>
> Thank you, Phil
> The latter suggestion is actually what I planned to do, with nginx handle
> the path
Jim, good point
The assumption is not from me, but from me guessing from a response by
Puma's member.
Anyway, I already asked him to clarify why would a lock occurred.
You can follow how it goes here:
https://github.com/puma/puma/issues/1895
I genuinely believe I am not overthinking this
About 30 seconds of googling found that "IO operations such as database
calls, interacting with the file system, or making external http calls will
not lock the GIL." Unless you're frequently using up your thread pool and
forcing requests to wait for an available worker, it seems like you
Thank you, Phil
The latter suggestion is actually what I planned to do, with nginx handle
the path routing instead of having separated endpoints.
May I ask why did you switch away from the approach?
IMHO, the approach is safer than mixing every request up in a single pool.
As I described, the
San Ji,
I think you have the situation where a user U sends a request to Rails app
A which in turn calls a service B. Then, service B makes a request back to
Rails app A, presumably for some additional information from the DB. You
want to make sure the second request from B to A does not
Hi Hassan
I don't because that would not solve my problem.
He was describing a kind of more usual deadlock caused by the global
interpreter lock.
Where Puma send the cyclic request to the same multithreaded worker, but
the worker was unable to process the latter request because of the GIL. (I
On Thu, Aug 8, 2019 at 10:00 PM San Ji wrote:
> They basiaclly said they receive this inquiry frequently, and they don't
> support it as they did not use it themselves.
> https://github.com/puma/puma/issues/1895
>
> I am still open for any pointers and suggestions.
> I wonder if there are other
No worry
And thank you again.
I also asked the Puma guy.
They basiaclly said they receive this inquiry frequently, and they don't
support it as they did not use it themselves.
https://github.com/puma/puma/issues/1895
I am still open for any pointers and suggestions. Maybe Puma guys just don't
San, I hope you know I meant no offense. This is a strange issue to have
and is normally indicative of an architectural design flaw and without
having more details that might violate your nda, we can only go based on
facts entered into evidence, to borrow a phase from legal.
An application can be
Architecture wise the application is way better than average Rails apps
IMO.
The dependency direction is one way internally, with no cyclic dependency.
(even with the ActiveRecord class, that in almost all other Rails app
contains cyclic dependency between models)
Network perspective may
hmm...
It sounds like you might want to isolate this into a micro-service then.
Honestly, and architecturally, it sounds like this process flow might need
a redesign, especially as it relies on a resource external to the main
application. I am guessing that this is legacy?
Is this application
Thank you for the reply, but the client is not a web browser, so no
javascript and no polling possible, plus not in our control.
To be more specific the call to the external service is via a headless
browser, not even a direct HTTP call, and you cannot push the data along
with the request made
It sounds like this might be best served by encapsulating the caller in a
job and then setting up a dedicated queue for that job in your background
processes, if I am understanding correctly what this is. If you need to
have the results display when complete then you could set up a poller or a
Hi
I run Rails on quite a complicated situation but the gist of it is, in my
application, it is possible that an action can call some external services
which fetch data from another action via another http call to the application
itself. (Basically a cyclic http call)
It is by design and there
14 matches
Mail list logo