{updated_time,{1328,815623,280614}}]}]}} in function gen_server:call/2 (gen_server.erl, line 180) in call from boss_record_lib:run_after_hooks/3 (src/boss/boss_record_lib.erl, line 11) in call from boss_db:save_record/1 (src/boss/boss_db.erl, line 195)
Only happens when creates a new boss_db record inside the boss_new:wath/2 fun, I'm in a multiapp setup (but started-dev from the app containing the init watches) and working with one node (dev).
The funny thing is that the new record is created, but the timeout+restart makes this ugly.
I think the problem is that the boss_news process is executing the callback, but the callback then sends a message to boss_news => deadlock. This is a design flaw. We need worker processes to execute the callbacks instead
Sent from my iPhone
On Feb 9, 2012, at 13:38, Jose Luis Gordo Romero <jgor...@gmail.com> wrote:
> activities:add(X) only adds a new record to a different model.
> When a record is inserted in modelx, the run_after_hooks timeouts:
> ** exception exit: {timeout,{gen_server,call, > [{global,boss_news}, > {created,"modelx-43", > [{id,"modelx-43"}, > ..... > {created_time,{1328,815623,280614}}, > {updated_time,{1328,815623,280614}}]}]}} > in function gen_server:call/2 (gen_server.erl, line 180) > in call from boss_record_lib:run_after_hooks/3 (src/boss/boss_record_lib.erl, line 11) > in call from boss_db:save_record/1 (src/boss/boss_db.erl, line 195)
> Only happens when creates a new boss_db record inside the boss_new:wath/2 fun, I'm in a multiapp setup (but started-dev from the app containing the init watches) and working with one node (dev).
> The funny thing is that the new record is created, but the timeout+restart makes this ugly.
> I think the problem is that the boss_news process is executing the > callback, but the callback then sends a message to boss_news => deadlock. > This is a design flaw. We need worker processes to execute the callbacks > instead
> Sent from my iPhone
> On Feb 9, 2012, at 13:38, Jose Luis Gordo Romero <jgor...@gmail.com> > wrote:
> Hi,
> I'm having problems with boss_news, I declared in the init the following:
> {updated_time,{1328,815623,280614}}]}]}} > in function gen_server:call/2 (gen_server.erl, line 180) > in call from boss_record_lib:run_after_hooks/3 > (src/boss/boss_record_lib.erl, line 11) > in call from boss_db:save_record/1 (src/boss/boss_db.erl, line 195)
> Only happens when creates a new boss_db record inside the boss_new:wath/2 > fun, I'm in a multiapp setup (but started-dev from the app containing the > init watches) and working with one node (dev).
> The funny thing is that the new record is created, but the timeout+restart > makes this ugly.
> 2012/2/9 Evan Miller <emmil...@gmail.com <mailto:emmil...@gmail.com>>
> I think the problem is that the boss_news process is executing the > callback, but the callback then sends a message to boss_news => > deadlock. This is a design flaw. We need worker processes to > execute the callbacks instead
> Sent from my iPhone
> On Feb 9, 2012, at 13:38, Jose Luis Gordo Romero > <jgor...@gmail.com <mailto:jgor...@gmail.com>> wrote:
>> Hi,
>> I'm having problems with boss_news, I declared in the init the >> following:
>> {updated_time,{1328,815623,280614}}]}]}} >> in function gen_server:call/2 (gen_server.erl, line 180) >> in call from boss_record_lib:run_after_hooks/3 >> (src/boss/boss_record_lib.erl, line 11) >> in call from boss_db:save_record/1 (src/boss/boss_db.erl, >> line 195)
>> Only happens when creates a new boss_db record inside the >> boss_new:wath/2 fun, I'm in a multiapp setup (but started-dev >> from the app containing the init watches) and working with one >> node (dev).
>> The funny thing is that the new record is created, but the >> timeout+restart makes this ugly.
>> I think the problem is that the boss_news process is executing the >> callback, but the callback then sends a message to boss_news => deadlock. >> This is a design flaw. We need worker processes to execute the callbacks >> instead
>> Sent from my iPhone
>> On Feb 9, 2012, at 13:38, Jose Luis Gordo Romero <jgor...@gmail.com> >> wrote:
>> Hi,
>> I'm having problems with boss_news, I declared in the init the following:
>> {updated_time,{1328,815623,280614}}]}]}} >> in function gen_server:call/2 (gen_server.erl, line 180) >> in call from boss_record_lib:run_after_hooks/3 >> (src/boss/boss_record_lib.erl, line 11) >> in call from boss_db:save_record/1 (src/boss/boss_db.erl, line 195)
>> Only happens when creates a new boss_db record inside the boss_new:wath/2 >> fun, I'm in a multiapp setup (but started-dev from the app containing the >> init watches) and working with one node (dev).
>> The funny thing is that the new record is created, but the timeout+restart >> makes this ugly.
> >> I think the problem is that the boss_news process is executing the > >> callback, but the callback then sends a message to boss_news => > deadlock. > >> This is a design flaw. We need worker processes to execute the callbacks > >> instead
> >> Sent from my iPhone
> >> On Feb 9, 2012, at 13:38, Jose Luis Gordo Romero <jgor...@gmail.com> > >> wrote:
> >> Hi,
> >> I'm having problems with boss_news, I declared in the init the > following:
> >> {updated_time,{1328,815623,280614}}]}]}} > >> in function gen_server:call/2 (gen_server.erl, line 180) > >> in call from boss_record_lib:run_after_hooks/3 > >> (src/boss/boss_record_lib.erl, line 11) > >> in call from boss_db:save_record/1 (src/boss/boss_db.erl, line 195)
> >> Only happens when creates a new boss_db record inside the > boss_new:wath/2 > >> fun, I'm in a multiapp setup (but started-dev from the app containing > the > >> init watches) and working with one node (dev).
> >> The funny thing is that the new record is created, but the > timeout+restart > >> makes this ugly.
> > 2012/2/9 Evan Miller <emmil...@gmail.com > <mailto:emmil...@gmail.com>>
> >> I think the problem is that the boss_news process is executing the > >> callback, but the callback then sends a message to boss_news => > deadlock. > >> This is a design flaw. We need worker processes to execute the > callbacks > >> instead
> >> Sent from my iPhone
> >> On Feb 9, 2012, at 13:38, Jose Luis Gordo Romero > <jgor...@gmail.com <mailto:jgor...@gmail.com>> > >> wrote:
> >> Hi,
> >> I'm having problems with boss_news, I declared in the init the > following:
> >> {updated_time,{1328,815623,280614}}]}]}} > >> in function gen_server:call/2 (gen_server.erl, line 180) > >> in call from boss_record_lib:run_after_hooks/3 > >> (src/boss/boss_record_lib.erl, line 11) > >> in call from boss_db:save_record/1 (src/boss/boss_db.erl, > line 195)
> >> Only happens when creates a new boss_db record inside the > boss_new:wath/2 > >> fun, I'm in a multiapp setup (but started-dev from the app > containing the > >> init watches) and working with one node (dev).
> >> The funny thing is that the new record is created, but the > timeout+restart > >> makes this ugly.
> For sharded <http://www.mongodb.org/display/DOCS/Sharding> > environments, each mongos process can perform any number of operations > concurrently. This results in downstream operations to mongod > instances. Execution of operations at each mongod is independent; that > is, one mongod does not block another.
On Fri, Feb 10, 2012 at 11:19 AM, Evan Miller <emmil...@gmail.com> wrote: > On Fri, Feb 10, 2012 at 1:21 AM, Jose Luis Gordo Romero > <jgor...@gmail.com> wrote: >> Thanks Evan,
>>> I think the problem is that the boss_news process is executing the >>> callback, but the callback then sends a message to boss_news => deadlock. >>> This is a design flaw. We need worker processes to execute the callbacks >>> instead
>>> Sent from my iPhone
>>> On Feb 9, 2012, at 13:38, Jose Luis Gordo Romero <jgor...@gmail.com> >>> wrote:
>>> Hi,
>>> I'm having problems with boss_news, I declared in the init the following:
>>> {updated_time,{1328,815623,280614}}]}]}} >>> in function gen_server:call/2 (gen_server.erl, line 180) >>> in call from boss_record_lib:run_after_hooks/3 >>> (src/boss/boss_record_lib.erl, line 11) >>> in call from boss_db:save_record/1 (src/boss/boss_db.erl, line 195)
>>> Only happens when creates a new boss_db record inside the boss_new:wath/2 >>> fun, I'm in a multiapp setup (but started-dev from the app containing the >>> init watches) and working with one node (dev).
>>> The funny thing is that the new record is created, but the timeout+restart >>> makes this ugly.
> There are also some UNTESTED poolboy commits in there, but I think the > above patch will solve the BossNews deadlock you encountered.
> On Fri, Feb 10, 2012 at 11:19 AM, Evan Miller <emmil...@gmail.com> wrote: > > On Fri, Feb 10, 2012 at 1:21 AM, Jose Luis Gordo Romero > > <jgor...@gmail.com> wrote: > >> Thanks Evan,
> >>> I think the problem is that the boss_news process is executing the > >>> callback, but the callback then sends a message to boss_news => > deadlock. > >>> This is a design flaw. We need worker processes to execute the > callbacks > >>> instead
> >>> Sent from my iPhone
> >>> On Feb 9, 2012, at 13:38, Jose Luis Gordo Romero <jgor...@gmail.com> > >>> wrote:
> >>> Hi,
> >>> I'm having problems with boss_news, I declared in the init the > following:
> >>> {updated_time,{1328,815623,280614}}]}]}} > >>> in function gen_server:call/2 (gen_server.erl, line 180) > >>> in call from boss_record_lib:run_after_hooks/3 > >>> (src/boss/boss_record_lib.erl, line 11) > >>> in call from boss_db:save_record/1 (src/boss/boss_db.erl, line > 195)
> >>> Only happens when creates a new boss_db record inside the > boss_new:wath/2 > >>> fun, I'm in a multiapp setup (but started-dev from the app containing > the > >>> init watches) and working with one node (dev).
> >>> The funny thing is that the new record is created, but the > timeout+restart > >>> makes this ugly.
