Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Memory monitor isn't there when FHC assumes it to be #157

Closed
michaelklishin opened this issue May 15, 2015 · 2 comments
Closed

Memory monitor isn't there when FHC assumes it to be #157

michaelklishin opened this issue May 15, 2015 · 2 comments
Assignees
@dumbbell
Labels
bug
Milestone
3.5.3

Comments

@michaelklishin
Copy link
Member

See this thread. My reading of it is that VM monitor isn't there when FHC assumes it is.
@michaelklishin michaelklishin added this to the 3.5.3 milestone May 15, 2015
@michaelklishin
Copy link
Member Author

Memory monitor is started by rabbit_alarm
which is started later than file_handle_cache, so if the FHC needs to go read
a lot of data from disk very early on, there's a race condition.

@michaelklishin michaelklishin mentioned this issue May 15, 2015
Merged
michaelklishin added a commit that referenced this issue May 19, 2015
@michaelklishin @dumbbell
Start rabbit_alarm before file_handle_cache
50577d6 
Since the FHC now uses memory monitor, we need to make sure it is
running early on. Nothing in rabbit_alarm really depends on the
steps that used to run earlier.

`full` test suite passes.

It may be worth extracting memory and disk monitors into separate
boot steps down the road.

While here, remove a comment that's misleading. Originally introduced as
part of bug24998, doesn't seem to have any significant reasoning behind
it other than "complete separation of FHC".

References #134.
Fixes #157.
@dumbbell
Copy link
Member

Since RabbitMQ 3.5.2.

dumbbell added a commit that referenced this issue May 21, 2015
@dumbbell
After starting the fhc, ensure it is working
c2cb043 
This is a runtime check to ensure the fix proposed in #157 actually
works.

References #157.
dumbbell added a commit that referenced this issue May 21, 2015
@dumbbell
After starting the fhc, ensure it is working
10e54dd 
This is a runtime check to ensure the fix proposed in #157 actually
works.

Export rabbit_table:wait_timeout/0 which returns the value of
'mnesia_table_loading_timeout' or 30000.

References #157.
dumbbell added a commit that referenced this issue May 21, 2015
@dumbbell
After starting the fhc, ensure it is working
b710efc 
This is a runtime check to ensure the fix proposed in #157 actually
works.

Export rabbit_table:wait_timeout/0 which returns the value of
'mnesia_table_loading_timeout' or 30000. We then use this timeout while
waiting for the fhc test to finish.

References #157.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@dumbbell dumbbell

Labels
bug
Projects
None yet
Milestone
3.5.3
Development

No branches or pull requests
2 participants
@michaelklishin @dumbbell