[jira] [Commented] (MESOS-3126) Building mesos.jar, uses old javadoc plugin in maven.
[ https://issues.apache.org/jira/browse/MESOS-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642745#comment-14642745 ] Hans van den Bogert commented on MESOS-3126: Well.. serves me right for not following the instructions to the letter. I was using the sun/oracle-jdk. Changing to sun-jdk-6, or openjdk-7 resolves this. Pretty weird though. I've made a proof of failure in Docker. Is a Dockerfile for Centos perhaps a good thing to have anyway in the git repo? Building mesos.jar, uses old javadoc plugin in maven. - Key: MESOS-3126 URL: https://issues.apache.org/jira/browse/MESOS-3126 Project: Mesos Issue Type: Bug Components: build Affects Versions: 0.23.0 Environment: Centos 6.5. Manually installed maven, version 3.3.3 Manually installing mesos. Reporter: Hans van den Bogert Priority: Minor When building Mesos, including the mesos.jar. It errors when generating the javadoc: http://pastebin.com/TNRERS4p It seems the javadoc plugin is also trying to parse .class files, though the source directories are correct in the pom file. Further investigation leads to think that the javadoc plugin version is to blame. Setting a fixed version of 2.10.3 for the javadoc plugin, in the pom file, successfully generates the javadoc. In this environment, the default javadoc plugin being downloaded, is 2.8.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3126) Building mesos.jar, uses old javadoc plugin in maven.
[ https://issues.apache.org/jira/browse/MESOS-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642756#comment-14642756 ] haosdent commented on MESOS-3126: - You could try this docker image. https://registry.hub.docker.com/u/mesosphere/mesos/ Building mesos.jar, uses old javadoc plugin in maven. - Key: MESOS-3126 URL: https://issues.apache.org/jira/browse/MESOS-3126 Project: Mesos Issue Type: Bug Components: build Affects Versions: 0.23.0 Environment: Centos 6.5. Manually installed maven, version 3.3.3 Manually installing mesos. Reporter: Hans van den Bogert Priority: Minor When building Mesos, including the mesos.jar. It errors when generating the javadoc: http://pastebin.com/TNRERS4p It seems the javadoc plugin is also trying to parse .class files, though the source directories are correct in the pom file. Further investigation leads to think that the javadoc plugin version is to blame. Setting a fixed version of 2.10.3 for the javadoc plugin, in the pom file, successfully generates the javadoc. In this environment, the default javadoc plugin being downloaded, is 2.8.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2697) Add a /teardown endpoint on master to teardown a framework
[ https://issues.apache.org/jira/browse/MESOS-2697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642691#comment-14642691 ] Till Toenshoff commented on MESOS-2697: --- commit 90f3fec71535bdf9c0cd5fc90c62e19a86b92470 Author: Joerg Schad jo...@mesosphere.io Date: Mon Jul 27 14:17:12 2015 +0200 Updated Authorization documentation to use /teardown endpoint. With Mesos 0.23 the /shutdown endpoint has been deprecated in favor of the /teardown endpoint. See MESOS-2697 for details. Review: https://reviews.apache.org/r/36774 Add a /teardown endpoint on master to teardown a framework -- Key: MESOS-2697 URL: https://issues.apache.org/jira/browse/MESOS-2697 Project: Mesos Issue Type: Task Reporter: Vinod Kone Assignee: Vinod Kone Fix For: 0.23.0 We plan to rename /shutdown endpoint to /teardown to be compatible with the new API. /shutdown will be deprecated in 0.24.0 or later. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-3152) Need for HTTP delete requests
Joerg Schad created MESOS-3152: -- Summary: Need for HTTP delete requests Key: MESOS-3152 URL: https://issues.apache.org/jira/browse/MESOS-3152 Project: Mesos Issue Type: Improvement Reporter: Joerg Schad As we decided to create a more restful api for managing Quota request, we also want to use the HTTP Delete method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3144) Update Homebrew formula for Mesos (Mac OSX)
[
https://issues.apache.org/jira/browse/MESOS-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14643124#comment-14643124
]
Marco Massenzio commented on MESOS-3144:
Hi, thanks for looking into it.
You can probably make a pull request, but I think it's easier if I just copy
your stuff (the SHA-256 were the blocking issue) into my PR (it's already there
and the Homebrew folks are ready to merge it).
Thanks!
Update Homebrew formula for Mesos (Mac OSX)
---
Key: MESOS-3144
URL: https://issues.apache.org/jira/browse/MESOS-3144
Project: Mesos
Issue Type: Task
Reporter: Marco Massenzio
Priority: Trivial
Labels: newbie
We have pushed a [pull
request|https://github.com/Homebrew/homebrew/pull/42099] to Homebrew for the
new 0.23 formula.
Once accepted, we must verify that this works on a Mac OSX device.
This would also be a great time to ensure our documentation is up-to-date.
Currently, the Homebrew check fails, as they have deprecated SHA-1 checksums:
{noformat}
Error Message
failed: brew audit mesos
Stacktrace
Error: 7 problems in 1 formula
mesos:
* Stable resource protobuf: SHA1 checksums are deprecated, please use
SHA256
* Stable resource python-gflags: SHA1 checksums are deprecated, please use
SHA256
* Stable resource six: SHA1 checksums are deprecated, please use SHA256
* Stable resource google-apputils: SHA1 checksums are deprecated, please
use SHA256
* Stable resource python-dateutil: SHA1 checksums are deprecated, please
use SHA256
* Stable resource boto: SHA1 checksums are deprecated, please use SHA256
* Stable resource pytz: SHA1 checksums are deprecated, please use SHA256
{noformat}
Don't know enough about Homebrew to really figure out what is going on here;
nor how to fix this.
The Mesos SHA-256 has been correctly entered and computed via the [Online
SHA/MD5 calculator|https://md5file.com/calculator].
I guess, we should go download the packages and compute their SHA-256 and/or
research from the respective download sites whether they publish the SHA.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-3154) Enable Mesos Agent Node to use arbitrary script / module to figure out IP, HOSTNAME
Marco Massenzio created MESOS-3154:
--
Summary: Enable Mesos Agent Node to use arbitrary script / module
to figure out IP, HOSTNAME
Key: MESOS-3154
URL: https://issues.apache.org/jira/browse/MESOS-3154
Project: Mesos
Issue Type: Story
Components: slave
Reporter: Benjamin Hindman
Assignee: Marco Massenzio
Following from MESOS-2902 we want to enable the same functionality in the Mesos
Agents too.
This is probably best done once we implement the new {{os::shell}} semantics,
as described in MESOS-3142.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-3153) Add tests for HTTPS SSL socket connection
Jojy Varghese created MESOS-3153: Summary: Add tests for HTTPS SSL socket connection Key: MESOS-3153 URL: https://issues.apache.org/jira/browse/MESOS-3153 Project: Mesos Issue Type: Bug Reporter: Jojy Varghese Assignee: Jojy Varghese Priority: Minor Unit tests are lacking for the following cases: 1. HTTPS Post with None payload. 2. http - ssl socket 3. https - raw socket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3126) Building mesos.jar, uses old javadoc plugin in maven.
[ https://issues.apache.org/jira/browse/MESOS-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14643054#comment-14643054 ] Vinod Kone commented on MESOS-3126: --- [~hbogert] ASF CI builds and testsMesos using the following Dockerfile for ubuntu:14 and centos:7 https://github.com/apache/mesos/blob/master/support/jenkins_build.sh Building mesos.jar, uses old javadoc plugin in maven. - Key: MESOS-3126 URL: https://issues.apache.org/jira/browse/MESOS-3126 Project: Mesos Issue Type: Bug Components: build Affects Versions: 0.23.0 Environment: Centos 6.5. Manually installed maven, version 3.3.3 Manually installing mesos. Reporter: Hans van den Bogert Priority: Minor When building Mesos, including the mesos.jar. It errors when generating the javadoc: http://pastebin.com/TNRERS4p It seems the javadoc plugin is also trying to parse .class files, though the source directories are correct in the pom file. Further investigation leads to think that the javadoc plugin version is to blame. Setting a fixed version of 2.10.3 for the javadoc plugin, in the pom file, successfully generates the javadoc. In this environment, the default javadoc plugin being downloaded, is 2.8.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3153) Add tests for HTTPS SSL socket communication
[ https://issues.apache.org/jira/browse/MESOS-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jojy Varghese updated MESOS-3153: - Description: Unit tests are lacking for the following cases: 1. HTTPS Post with None payload. 2. Verification of HTTPS payload on the SSL socket(maybe decode to a Request object) 3. http - ssl socket 4. https - raw socket. was: Unit tests are lacking for the following cases: 1. HTTPS Post with None payload. 2. http - ssl socket 3. https - raw socket. Add tests for HTTPS SSL socket communication Key: MESOS-3153 URL: https://issues.apache.org/jira/browse/MESOS-3153 Project: Mesos Issue Type: Bug Reporter: Jojy Varghese Assignee: Jojy Varghese Priority: Minor Labels: mesosphere Unit tests are lacking for the following cases: 1. HTTPS Post with None payload. 2. Verification of HTTPS payload on the SSL socket(maybe decode to a Request object) 3. http - ssl socket 4. https - raw socket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (MESOS-3144) Update Homebrew formula for Mesos (Mac OSX)
[
https://issues.apache.org/jira/browse/MESOS-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Massenzio updated MESOS-3144:
---
Comment: was deleted
(was: Uploaded a new PR: https://github.com/Homebrew/homebrew/pull/42177)
Update Homebrew formula for Mesos (Mac OSX)
---
Key: MESOS-3144
URL: https://issues.apache.org/jira/browse/MESOS-3144
Project: Mesos
Issue Type: Task
Reporter: Marco Massenzio
Priority: Trivial
Labels: newbie
We have pushed a [pull
request|https://github.com/Homebrew/homebrew/pull/42099] to Homebrew for the
new 0.23 formula.
Once accepted, we must verify that this works on a Mac OSX device.
This would also be a great time to ensure our documentation is up-to-date.
Currently, the Homebrew check fails, as they have deprecated SHA-1 checksums:
{noformat}
Error Message
failed: brew audit mesos
Stacktrace
Error: 7 problems in 1 formula
mesos:
* Stable resource protobuf: SHA1 checksums are deprecated, please use
SHA256
* Stable resource python-gflags: SHA1 checksums are deprecated, please use
SHA256
* Stable resource six: SHA1 checksums are deprecated, please use SHA256
* Stable resource google-apputils: SHA1 checksums are deprecated, please
use SHA256
* Stable resource python-dateutil: SHA1 checksums are deprecated, please
use SHA256
* Stable resource boto: SHA1 checksums are deprecated, please use SHA256
* Stable resource pytz: SHA1 checksums are deprecated, please use SHA256
{noformat}
Don't know enough about Homebrew to really figure out what is going on here;
nor how to fix this.
The Mesos SHA-256 has been correctly entered and computed via the [Online
SHA/MD5 calculator|https://md5file.com/calculator].
I guess, we should go download the packages and compute their SHA-256 and/or
research from the respective download sites whether they publish the SHA.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3144) Update Homebrew formula for Mesos (Mac OSX)
[
https://issues.apache.org/jira/browse/MESOS-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14643140#comment-14643140
]
Marco Massenzio commented on MESOS-3144:
Uploaded a new PR: https://github.com/Homebrew/homebrew/pull/42177
Update Homebrew formula for Mesos (Mac OSX)
---
Key: MESOS-3144
URL: https://issues.apache.org/jira/browse/MESOS-3144
Project: Mesos
Issue Type: Task
Reporter: Marco Massenzio
Priority: Trivial
Labels: newbie
We have pushed a [pull
request|https://github.com/Homebrew/homebrew/pull/42099] to Homebrew for the
new 0.23 formula.
Once accepted, we must verify that this works on a Mac OSX device.
This would also be a great time to ensure our documentation is up-to-date.
Currently, the Homebrew check fails, as they have deprecated SHA-1 checksums:
{noformat}
Error Message
failed: brew audit mesos
Stacktrace
Error: 7 problems in 1 formula
mesos:
* Stable resource protobuf: SHA1 checksums are deprecated, please use
SHA256
* Stable resource python-gflags: SHA1 checksums are deprecated, please use
SHA256
* Stable resource six: SHA1 checksums are deprecated, please use SHA256
* Stable resource google-apputils: SHA1 checksums are deprecated, please
use SHA256
* Stable resource python-dateutil: SHA1 checksums are deprecated, please
use SHA256
* Stable resource boto: SHA1 checksums are deprecated, please use SHA256
* Stable resource pytz: SHA1 checksums are deprecated, please use SHA256
{noformat}
Don't know enough about Homebrew to really figure out what is going on here;
nor how to fix this.
The Mesos SHA-256 has been correctly entered and computed via the [Online
SHA/MD5 calculator|https://md5file.com/calculator].
I guess, we should go download the packages and compute their SHA-256 and/or
research from the respective download sites whether they publish the SHA.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-3144) Update Homebrew formula for Mesos (Mac OSX)
[
https://issues.apache.org/jira/browse/MESOS-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Massenzio reassigned MESOS-3144:
--
Assignee: Marco Massenzio
Update Homebrew formula for Mesos (Mac OSX)
---
Key: MESOS-3144
URL: https://issues.apache.org/jira/browse/MESOS-3144
Project: Mesos
Issue Type: Task
Reporter: Marco Massenzio
Assignee: Marco Massenzio
Priority: Trivial
Labels: newbie
We have pushed a [pull
request|https://github.com/Homebrew/homebrew/pull/42099] to Homebrew for the
new 0.23 formula.
Once accepted, we must verify that this works on a Mac OSX device.
This would also be a great time to ensure our documentation is up-to-date.
Currently, the Homebrew check fails, as they have deprecated SHA-1 checksums:
{noformat}
Error Message
failed: brew audit mesos
Stacktrace
Error: 7 problems in 1 formula
mesos:
* Stable resource protobuf: SHA1 checksums are deprecated, please use
SHA256
* Stable resource python-gflags: SHA1 checksums are deprecated, please use
SHA256
* Stable resource six: SHA1 checksums are deprecated, please use SHA256
* Stable resource google-apputils: SHA1 checksums are deprecated, please
use SHA256
* Stable resource python-dateutil: SHA1 checksums are deprecated, please
use SHA256
* Stable resource boto: SHA1 checksums are deprecated, please use SHA256
* Stable resource pytz: SHA1 checksums are deprecated, please use SHA256
{noformat}
Don't know enough about Homebrew to really figure out what is going on here;
nor how to fix this.
The Mesos SHA-256 has been correctly entered and computed via the [Online
SHA/MD5 calculator|https://md5file.com/calculator].
I guess, we should go download the packages and compute their SHA-256 and/or
research from the respective download sites whether they publish the SHA.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-3144) Update Homebrew formula for Mesos (Mac OSX)
[
https://issues.apache.org/jira/browse/MESOS-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Massenzio updated MESOS-3144:
---
Sprint: Mesosphere Sprint 15
Labels: mesosphere newbie (was: newbie)
Update Homebrew formula for Mesos (Mac OSX)
---
Key: MESOS-3144
URL: https://issues.apache.org/jira/browse/MESOS-3144
Project: Mesos
Issue Type: Task
Reporter: Marco Massenzio
Assignee: Marco Massenzio
Priority: Trivial
Labels: mesosphere, newbie
We have pushed a [pull
request|https://github.com/Homebrew/homebrew/pull/42099] to Homebrew for the
new 0.23 formula.
Once accepted, we must verify that this works on a Mac OSX device.
This would also be a great time to ensure our documentation is up-to-date.
Currently, the Homebrew check fails, as they have deprecated SHA-1 checksums:
{noformat}
Error Message
failed: brew audit mesos
Stacktrace
Error: 7 problems in 1 formula
mesos:
* Stable resource protobuf: SHA1 checksums are deprecated, please use
SHA256
* Stable resource python-gflags: SHA1 checksums are deprecated, please use
SHA256
* Stable resource six: SHA1 checksums are deprecated, please use SHA256
* Stable resource google-apputils: SHA1 checksums are deprecated, please
use SHA256
* Stable resource python-dateutil: SHA1 checksums are deprecated, please
use SHA256
* Stable resource boto: SHA1 checksums are deprecated, please use SHA256
* Stable resource pytz: SHA1 checksums are deprecated, please use SHA256
{noformat}
Don't know enough about Homebrew to really figure out what is going on here;
nor how to fix this.
The Mesos SHA-256 has been correctly entered and computed via the [Online
SHA/MD5 calculator|https://md5file.com/calculator].
I guess, we should go download the packages and compute their SHA-256 and/or
research from the respective download sites whether they publish the SHA.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-3153) Add tests for HTTPS SSL socket communication
[ https://issues.apache.org/jira/browse/MESOS-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jojy Varghese updated MESOS-3153: - Summary: Add tests for HTTPS SSL socket communication (was: Add tests for HTTPS SSL socket connection) Add tests for HTTPS SSL socket communication Key: MESOS-3153 URL: https://issues.apache.org/jira/browse/MESOS-3153 Project: Mesos Issue Type: Bug Reporter: Jojy Varghese Assignee: Jojy Varghese Priority: Minor Labels: mesosphere Unit tests are lacking for the following cases: 1. HTTPS Post with None payload. 2. http - ssl socket 3. https - raw socket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-830) ExamplesTest.JavaFramework is flaky
[ https://issues.apache.org/jira/browse/MESOS-830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marco Massenzio updated MESOS-830: -- Sprint: Mesosphere Sprint 16 ExamplesTest.JavaFramework is flaky --- Key: MESOS-830 URL: https://issues.apache.org/jira/browse/MESOS-830 Project: Mesos Issue Type: Bug Components: test Reporter: Vinod Kone Assignee: Greg Mann Labels: flaky, mesosphere [ RUN ] ExamplesTest.JavaFramework Using temporary directory '/tmp/ExamplesTest_JavaFramework_wSc7u8' Enabling authentication for the framework I1120 15:13:39.820032 1681264640 master.cpp:285] Master started on 172.25.133.171:52576 I1120 15:13:39.820180 1681264640 master.cpp:299] Master ID: 201311201513-2877626796-52576-3234 I1120 15:13:39.820194 1681264640 master.cpp:302] Master only allowing authenticated frameworks to register! I1120 15:13:39.821197 1679654912 slave.cpp:112] Slave started on 1)@172.25.133.171:52576 I1120 15:13:39.821795 1679654912 slave.cpp:212] Slave resources: cpus(*):4; mem(*):7168; disk(*):481998; ports(*):[31000-32000] I1120 15:13:39.822855 1682337792 slave.cpp:112] Slave started on 2)@172.25.133.171:52576 I1120 15:13:39.823652 1682337792 slave.cpp:212] Slave resources: cpus(*):4; mem(*):7168; disk(*):481998; ports(*):[31000-32000] I1120 15:13:39.825330 1679118336 master.cpp:744] The newly elected leader is master@172.25.133.171:52576 I1120 15:13:39.825445 1679118336 master.cpp:748] Elected as the leading master! I1120 15:13:39.825907 1681264640 state.cpp:33] Recovering state from '/tmp/ExamplesTest_JavaFramework_wSc7u8/0/meta' I1120 15:13:39.826127 1681264640 status_update_manager.cpp:180] Recovering status update manager I1120 15:13:39.826331 1681801216 process_isolator.cpp:317] Recovering isolator I1120 15:13:39.826738 1682874368 slave.cpp:2743] Finished recovery I1120 15:13:39.827747 1682337792 state.cpp:33] Recovering state from '/tmp/ExamplesTest_JavaFramework_wSc7u8/1/meta' I1120 15:13:39.827945 1680191488 slave.cpp:112] Slave started on 3)@172.25.133.171:52576 I1120 15:13:39.828415 1682337792 status_update_manager.cpp:180] Recovering status update manager I1120 15:13:39.828608 1680728064 sched.cpp:260] Authenticating with master master@172.25.133.171:52576 I1120 15:13:39.828606 1680191488 slave.cpp:212] Slave resources: cpus(*):4; mem(*):7168; disk(*):481998; ports(*):[31000-32000] I1120 15:13:39.828680 1682874368 slave.cpp:497] New master detected at master@172.25.133.171:52576 I1120 15:13:39.828765 1682337792 process_isolator.cpp:317] Recovering isolator I1120 15:13:39.829828 1680728064 sched.cpp:229] Detecting new master I1120 15:13:39.830288 1679654912 authenticatee.hpp:100] Initializing client SASL I1120 15:13:39.831635 1680191488 state.cpp:33] Recovering state from '/tmp/ExamplesTest_JavaFramework_wSc7u8/2/meta' I1120 15:13:39.831991 1679118336 status_update_manager.cpp:158] New master detected at master@172.25.133.171:52576 I1120 15:13:39.832042 1682874368 slave.cpp:524] Detecting new master I1120 15:13:39.832314 1682337792 slave.cpp:2743] Finished recovery I1120 15:13:39.832309 1681264640 master.cpp:1266] Attempting to register slave on vkone.local at slave(1)@172.25.133.171:52576 I1120 15:13:39.832929 1680728064 status_update_manager.cpp:180] Recovering status update manager I1120 15:13:39.833371 1681801216 slave.cpp:497] New master detected at master@172.25.133.171:52576 I1120 15:13:39.833273 1681264640 master.cpp:2513] Adding slave 201311201513-2877626796-52576-3234-0 at vkone.local with cpus(*):4; mem(*):7168; disk(*):481998; ports(*):[31000-32000] I1120 15:13:39.833595 1680728064 process_isolator.cpp:317] Recovering isolator I1120 15:13:39.833859 1681801216 slave.cpp:524] Detecting new master I1120 15:13:39.833861 1682874368 status_update_manager.cpp:158] New master detected at master@172.25.133.171:52576 I1120 15:13:39.834092 1680191488 slave.cpp:542] Registered with master master@172.25.133.171:52576; given slave ID 201311201513-2877626796-52576-3234-0 I1120 15:13:39.834486 1681264640 master.cpp:1266] Attempting to register slave on vkone.local at slave(2)@172.25.133.171:52576 I1120 15:13:39.834549 1681264640 master.cpp:2513] Adding slave 201311201513-2877626796-52576-3234-1 at vkone.local with cpus(*):4; mem(*):7168; disk(*):481998; ports(*):[31000-32000] I1120 15:13:39.834750 1680191488 slave.cpp:555] Checkpointing SlaveInfo to '/tmp/ExamplesTest_JavaFramework_wSc7u8/0/meta/slaves/201311201513-2877626796-52576-3234-0/slave.info' I1120 15:13:39.834875 1682874368 hierarchical_allocator_process.hpp:445] Added slave 201311201513-2877626796-52576-3234-0 (vkone.local) with cpus(*):4; mem(*):7168; disk(*):481998; ports(*):[31000-32000] (and cpus(*):4; mem(*):7168;
[jira] [Updated] (MESOS-1010) Python extension build is broken if gflags-dev is installed
[
https://issues.apache.org/jira/browse/MESOS-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Massenzio updated MESOS-1010:
---
Sprint: Mesosphere Sprint 16
Python extension build is broken if gflags-dev is installed
---
Key: MESOS-1010
URL: https://issues.apache.org/jira/browse/MESOS-1010
Project: Mesos
Issue Type: Bug
Components: build, python api
Environment: Fedora 20, amd64. GCC: 4.8.2.
Reporter: Nikita Vetoshkin
Assignee: Greg Mann
Labels: flaky-test, mesosphere
In my environment mesos build from master results in broken python api module
{{_mesos.so}}:
{noformat}
nekto0n@ya-darkstar ~/workspace/mesos/src/python $
PYTHONPATH=build/lib.linux-x86_64-2.7/ python -c import _mesos
Traceback (most recent call last):
File string, line 1, in module
ImportError:
/home/nekto0n/workspace/mesos/src/python/build/lib.linux-x86_64-2.7/_mesos.so:
undefined symbol: _ZN6google14FlagRegistererC1EPKcS2_S2_S2_PvS3_
{noformat}
Unmangled version of symbol looks like this:
{noformat}
google::FlagRegisterer::FlagRegisterer(char const*, char const*, char const*,
char const*, void*, void*)
{noformat}
During {{./configure}} step {{glog}} finds {{gflags}} development files and
starts using them, thus *implicitly* adding dependency on {{libgflags.so}}.
This breaks Python extensions module and perhaps can break other mesos
subsystems when moved to hosts without {{gflags}} installed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3057) Mesos web ui sorting by Id results in non-intuitive order.
[ https://issues.apache.org/jira/browse/MESOS-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14643185#comment-14643185 ] Cody Roseborough commented on MESOS-3057: - The one pictured is: [Mesosaurus| https://github.com/mesosphere/mesosaurus]. Came across it while testing other things and it seemed counter to what you would expect. It seems like it would effect orderings on any framework that used numbers as part of it's task_id's? Mesos web ui sorting by Id results in non-intuitive order. -- Key: MESOS-3057 URL: https://issues.apache.org/jira/browse/MESOS-3057 Project: Mesos Issue Type: Bug Affects Versions: 0.23.0 Reporter: Cody Roseborough Priority: Trivial Labels: newbie Attachments: web ui sorted by ids.png In the mesos webui sorting task by ID results in non-intuitive order. For example with Id's task_0-task_200 sorted asc you get task_0, task_1, task_10, task_100... task_109, task_11, task_110 etc. It happens if you use just numbers as Id's also. It seems like it should be sorted using natural sort order. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3141) Compiler warning when mocking function type has an enum return type.
[
https://issues.apache.org/jira/browse/MESOS-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14643244#comment-14643244
]
Marco Massenzio commented on MESOS-3141:
That's probably because RB assumes sane behavior :)
This points to a larger issue (which I am not sure anyone ever looked into or
is there even a Jira for?) that we should not store binaries/libraries inside
Mesos repo (eg, protobuf; zookeeper; gmock; other stuff I forget now, I'm
sure...)
Before making this change, we should really ensure this doesn't cause build
failures on *all* supported OSes (Ubuntu/CentOS/RHEL) or we'll only find out at
release time, and that will be really A Bad Thing.
I'm all for upgrading gmock, but let's please proceed carefully here.
Compiler warning when mocking function type has an enum return type.
Key: MESOS-3141
URL: https://issues.apache.org/jira/browse/MESOS-3141
Project: Mesos
Issue Type: Bug
Affects Versions: 0.23.0
Reporter: Michael Park
Assignee: haosdent
Labels: mesosphere
The purpose of this ticket is to document a very cryptic error message
(actually a warning that gets propagated by {{-Werror}}) that gets generated
by {{clang-3.5}} from {{gmock}} source code when trying to mock a perfectly
innocent-looking function.
h3. Problem
The following code is attempting to mock a {{MesosExecutorDriver}}:
{code}
class MockMesosExecutorDriver : public MesosExecutorDriver {
public:
MockMesosExecutorDriver(mesos::Executor* executor)
: MesosExecutorDriver(executor) {}
MOCK_METHOD1(sendStatusUpdate, Status(const TaskStatus));
};
{code}
The above code generates the following error message:
{noformat}
In file included from
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock.h:58:
In file included from
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:46:
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h:355:10:
error: indirection of non-volatile null pointer will be deleted, not trap
[-Werror,-Wnull-dereference]
return *static_casttypename remove_referenceT::type*(__null);
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:78:22:
note: in instantiation of function template specialization
'testing::internal::Invalidmesos::Status' requested here
return internal::InvalidT();
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:190:43:
note: in instantiation of member function
'testing::internal::BuiltInDefaultValuemesos::Status::Get' requested here
internal::BuiltInDefaultValueT::Get() : *value_;
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1435:34:
note: in instantiation of member function
'testing::DefaultValuemesos::Status::Get' requested here
return DefaultValueResult::Get();
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1334:22:
note: in instantiation of member function
'testing::internal::FunctionMockerBasemesos::Status (const mesos::TaskStatus
)::PerformDefaultAction' requested here
func_mocker-PerformDefaultAction(args, call_description));
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1448:26:
note: in instantiation of function template specialization
'testing::internal::ActionResultHoldermesos::Status::PerformDefaultActionmesos::Status
(const mesos::TaskStatus )' requested here
return ResultHolder::PerformDefaultAction(this, args, call_description);
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-generated-function-mockers.h:81:7:
note: in instantiation of member function
'testing::internal::FunctionMockerBasemesos::Status (const mesos::TaskStatus
)::UntypedPerformDefaultAction' requested here
class FunctionMockerR(A1) : public
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h:355:10:
note: consider using __builtin_trap() or qualifying pointer with 'volatile'
return *static_casttypename remove_referenceT::type*(__null);
^
{noformat}
The source of the issue here is that {{Status}} is an {{enum}}. In
{{gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h}} you can find
the following function:
{code}
template typename T
T Invalid() {
return *static_casttypename remove_referenceT::type*(NULL);
}
{code}
This function gets called with the return type of a mocked function. In our
case, the return type
[jira] [Comment Edited] (MESOS-3101) Standardize separation of Windows/Linux-specific OS code
[ https://issues.apache.org/jira/browse/MESOS-3101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14643256#comment-14643256 ] Marco Massenzio edited comment on MESOS-3101 at 7/27/15 7:36 PM: - It's a bit confusing, I must admit. to have a story out with the review already in the description. Is the review a precursor to this story? is there a bigger/better review to be had? And should this be in Reviewable already? If the work spans such a large number of files in a non-trivial way, maybe (a) you probably are underestimating the points and (b) perhaps you want to chunk the work in smaller stories/tasks? I dread us ending in the same situation as MESOS-2860, where ONE Jira task spawned 10 reviews... was (Author: marco-mesos): You seem to have a review out for this one? care to move this to Reviewable and add a link to the review? Standardize separation of Windows/Linux-specific OS code Key: MESOS-3101 URL: https://issues.apache.org/jira/browse/MESOS-3101 Project: Mesos Issue Type: Task Components: stout Reporter: Joseph Wu Assignee: Joseph Wu Labels: mesosphere There are 50+ files that must be touched to separate OS-specific code. First, we will standardize the changes by using stout/abort.hpp as an example. The review/discussion can be found here: https://reviews.apache.org/r/36625/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-3155) Add a containerizer and executor that simulate the launching of tasks.
[ https://issues.apache.org/jira/browse/MESOS-3155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cody Roseborough reassigned MESOS-3155: --- Assignee: Cody Roseborough Add a containerizer and executor that simulate the launching of tasks. --- Key: MESOS-3155 URL: https://issues.apache.org/jira/browse/MESOS-3155 Project: Mesos Issue Type: Improvement Components: containerization, slave Reporter: Cody Roseborough Assignee: Cody Roseborough Priority: Minor This could have a user-defined configuration file. This would allow users to locally test frameworks against a large, simulated cluster using mesos-local. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3155) Add a containerizer and executor that simulate the launching of tasks.
[ https://issues.apache.org/jira/browse/MESOS-3155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cody Roseborough updated MESOS-3155: Description: This could have a user-defined configuration file. This would allow users to locally test frameworks against a large, simulated cluster using mesos-local. Add a containerizer and executor that simulate the launching of tasks. --- Key: MESOS-3155 URL: https://issues.apache.org/jira/browse/MESOS-3155 Project: Mesos Issue Type: Improvement Components: containerization, slave Reporter: Cody Roseborough Priority: Minor This could have a user-defined configuration file. This would allow users to locally test frameworks against a large, simulated cluster using mesos-local. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2757) Can't Use - operator with OptionT, TryT, ResultT, FutureT
[ https://issues.apache.org/jira/browse/MESOS-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14643226#comment-14643226 ] Benjamin Mahler commented on MESOS-2757: Adding the operators sounds good to me. Can't Use - operator with OptionT, TryT, ResultT, FutureT -- Key: MESOS-2757 URL: https://issues.apache.org/jira/browse/MESOS-2757 Project: Mesos Issue Type: Improvement Components: stout Reporter: Joris Van Remoortere Assignee: Joris Van Remoortere Labels: c++11, mesosphere, option, stout Let's add operator overloads to OptionT to allow access to the underlying T using the `-` operator. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-1815) Create a guide to becoming a committer
[ https://issues.apache.org/jira/browse/MESOS-1815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14643168#comment-14643168 ] Marco Massenzio commented on MESOS-1815: Hey [~bernd-mesos] - any progress on this one? What's missing/blocking? Last comment was 20days ago; any progress/blockers? Create a guide to becoming a committer -- Key: MESOS-1815 URL: https://issues.apache.org/jira/browse/MESOS-1815 Project: Mesos Issue Type: Documentation Components: documentation Reporter: Dominic Hamon Assignee: Bernd Mathiske Labels: mesosphere We have a committer's guide, but the process by which one becomes a committer is unclear. We should set some guidelines and a process by which we can grow contributors into committers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-3155) Add a containerizer and executor that simulate the launching of tasks using a user-defined configuration file. Allows users to locally test frameworks against a large, si
Cody Roseborough created MESOS-3155: --- Summary: Add a containerizer and executor that simulate the launching of tasks using a user-defined configuration file. Allows users to locally test frameworks against a large, simulated cluster using mesos-local Key: MESOS-3155 URL: https://issues.apache.org/jira/browse/MESOS-3155 Project: Mesos Issue Type: Improvement Components: containerization, slave Reporter: Cody Roseborough Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3046) Stout's UUID re-seeds a new random generator during each call to UUID::random.
[
https://issues.apache.org/jira/browse/MESOS-3046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Mahler updated MESOS-3046:
---
Labels: newbie twitter (was: twitter)
Stout's UUID re-seeds a new random generator during each call to UUID::random.
--
Key: MESOS-3046
URL: https://issues.apache.org/jira/browse/MESOS-3046
Project: Mesos
Issue Type: Bug
Components: stout
Reporter: Benjamin Mahler
Labels: newbie, twitter
Per [~StephanErb] and [~kevints]'s observations on MESOS-2940, stout's UUID
abstraction is re-seeding the random generator during each call to
{{UUID::random()}}, which is really expensive.
This is confirmed in the perf graph from MESOS-2940.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-3155) Add a containerizer and executor that simulate the launching of tasks.
[ https://issues.apache.org/jira/browse/MESOS-3155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cody Roseborough updated MESOS-3155: Summary: Add a containerizer and executor that simulate the launching of tasks. (was: Add a containerizer and executor that simulate the launching of tasks using a user-defined configuration file. Allows users to locally test frameworks against a large, simulated cluster using mesos-local) Add a containerizer and executor that simulate the launching of tasks. --- Key: MESOS-3155 URL: https://issues.apache.org/jira/browse/MESOS-3155 Project: Mesos Issue Type: Improvement Components: containerization, slave Reporter: Cody Roseborough Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3101) Standardize separation of Windows/Linux-specific OS code
[ https://issues.apache.org/jira/browse/MESOS-3101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14643256#comment-14643256 ] Marco Massenzio commented on MESOS-3101: You seem to have a review out for this one? care to move this to Reviewable and add a link to the review? Standardize separation of Windows/Linux-specific OS code Key: MESOS-3101 URL: https://issues.apache.org/jira/browse/MESOS-3101 Project: Mesos Issue Type: Task Components: stout Reporter: Joseph Wu Assignee: Joseph Wu Labels: mesosphere There are 50+ files that must be touched to separate OS-specific code. First, we will standardize the changes by using stout/abort.hpp as an example. The review/discussion can be found here: https://reviews.apache.org/r/36625/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3141) Compiler warning when mocking function type has an enum return type.
[
https://issues.apache.org/jira/browse/MESOS-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14643289#comment-14643289
]
Michael Park commented on MESOS-3141:
-
[~haosd...@gmail.com] Thanks for doing this! From what I see on Reviewboard, it
looks like the problem is only with {{Mesos ReviewBot}} and the fact that
{{./support/apply-review.sh}} doesn't support applying patches that involve
binary or something? I don't see any complaints from Reviewboard itself. Am I
missing something?
Compiler warning when mocking function type has an enum return type.
Key: MESOS-3141
URL: https://issues.apache.org/jira/browse/MESOS-3141
Project: Mesos
Issue Type: Bug
Affects Versions: 0.23.0
Reporter: Michael Park
Assignee: haosdent
Labels: mesosphere
The purpose of this ticket is to document a very cryptic error message
(actually a warning that gets propagated by {{-Werror}}) that gets generated
by {{clang-3.5}} from {{gmock}} source code when trying to mock a perfectly
innocent-looking function.
h3. Problem
The following code is attempting to mock a {{MesosExecutorDriver}}:
{code}
class MockMesosExecutorDriver : public MesosExecutorDriver {
public:
MockMesosExecutorDriver(mesos::Executor* executor)
: MesosExecutorDriver(executor) {}
MOCK_METHOD1(sendStatusUpdate, Status(const TaskStatus));
};
{code}
The above code generates the following error message:
{noformat}
In file included from
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock.h:58:
In file included from
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:46:
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h:355:10:
error: indirection of non-volatile null pointer will be deleted, not trap
[-Werror,-Wnull-dereference]
return *static_casttypename remove_referenceT::type*(__null);
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:78:22:
note: in instantiation of function template specialization
'testing::internal::Invalidmesos::Status' requested here
return internal::InvalidT();
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:190:43:
note: in instantiation of member function
'testing::internal::BuiltInDefaultValuemesos::Status::Get' requested here
internal::BuiltInDefaultValueT::Get() : *value_;
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1435:34:
note: in instantiation of member function
'testing::DefaultValuemesos::Status::Get' requested here
return DefaultValueResult::Get();
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1334:22:
note: in instantiation of member function
'testing::internal::FunctionMockerBasemesos::Status (const mesos::TaskStatus
)::PerformDefaultAction' requested here
func_mocker-PerformDefaultAction(args, call_description));
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1448:26:
note: in instantiation of function template specialization
'testing::internal::ActionResultHoldermesos::Status::PerformDefaultActionmesos::Status
(const mesos::TaskStatus )' requested here
return ResultHolder::PerformDefaultAction(this, args, call_description);
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-generated-function-mockers.h:81:7:
note: in instantiation of member function
'testing::internal::FunctionMockerBasemesos::Status (const mesos::TaskStatus
)::UntypedPerformDefaultAction' requested here
class FunctionMockerR(A1) : public
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h:355:10:
note: consider using __builtin_trap() or qualifying pointer with 'volatile'
return *static_casttypename remove_referenceT::type*(__null);
^
{noformat}
The source of the issue here is that {{Status}} is an {{enum}}. In
{{gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h}} you can find
the following function:
{code}
template typename T
T Invalid() {
return *static_casttypename remove_referenceT::type*(NULL);
}
{code}
This function gets called with the return type of a mocked function. In our
case, the return type of the mocked function is {{Status}}.
Attempting to compile the following minimal example with {{clang-3.5}}
reproduces the error message:
{code}
#include type_traits
template typename T
T invalid() {
return *static_casttypename
[jira] [Commented] (MESOS-3141) Compiler warning when mocking function type has an enum return type.
[
https://issues.apache.org/jira/browse/MESOS-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14643300#comment-14643300
]
Michael Park commented on MESOS-3141:
-
[~marco-mesos] Unbundling our dependencies have been discussed in the past,
mostly driven by [~cmaloney] and [~benjaminhindman]. I'm not up to date with
the current status and what's coming, so I'll defer to them for a reply.
Compiler warning when mocking function type has an enum return type.
Key: MESOS-3141
URL: https://issues.apache.org/jira/browse/MESOS-3141
Project: Mesos
Issue Type: Bug
Affects Versions: 0.23.0
Reporter: Michael Park
Assignee: haosdent
Labels: mesosphere
The purpose of this ticket is to document a very cryptic error message
(actually a warning that gets propagated by {{-Werror}}) that gets generated
by {{clang-3.5}} from {{gmock}} source code when trying to mock a perfectly
innocent-looking function.
h3. Problem
The following code is attempting to mock a {{MesosExecutorDriver}}:
{code}
class MockMesosExecutorDriver : public MesosExecutorDriver {
public:
MockMesosExecutorDriver(mesos::Executor* executor)
: MesosExecutorDriver(executor) {}
MOCK_METHOD1(sendStatusUpdate, Status(const TaskStatus));
};
{code}
The above code generates the following error message:
{noformat}
In file included from
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock.h:58:
In file included from
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:46:
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h:355:10:
error: indirection of non-volatile null pointer will be deleted, not trap
[-Werror,-Wnull-dereference]
return *static_casttypename remove_referenceT::type*(__null);
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:78:22:
note: in instantiation of function template specialization
'testing::internal::Invalidmesos::Status' requested here
return internal::InvalidT();
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:190:43:
note: in instantiation of member function
'testing::internal::BuiltInDefaultValuemesos::Status::Get' requested here
internal::BuiltInDefaultValueT::Get() : *value_;
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1435:34:
note: in instantiation of member function
'testing::DefaultValuemesos::Status::Get' requested here
return DefaultValueResult::Get();
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1334:22:
note: in instantiation of member function
'testing::internal::FunctionMockerBasemesos::Status (const mesos::TaskStatus
)::PerformDefaultAction' requested here
func_mocker-PerformDefaultAction(args, call_description));
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1448:26:
note: in instantiation of function template specialization
'testing::internal::ActionResultHoldermesos::Status::PerformDefaultActionmesos::Status
(const mesos::TaskStatus )' requested here
return ResultHolder::PerformDefaultAction(this, args, call_description);
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-generated-function-mockers.h:81:7:
note: in instantiation of member function
'testing::internal::FunctionMockerBasemesos::Status (const mesos::TaskStatus
)::UntypedPerformDefaultAction' requested here
class FunctionMockerR(A1) : public
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h:355:10:
note: consider using __builtin_trap() or qualifying pointer with 'volatile'
return *static_casttypename remove_referenceT::type*(__null);
^
{noformat}
The source of the issue here is that {{Status}} is an {{enum}}. In
{{gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h}} you can find
the following function:
{code}
template typename T
T Invalid() {
return *static_casttypename remove_referenceT::type*(NULL);
}
{code}
This function gets called with the return type of a mocked function. In our
case, the return type of the mocked function is {{Status}}.
Attempting to compile the following minimal example with {{clang-3.5}}
reproduces the error message:
{code}
#include type_traits
template typename T
T invalid() {
return *static_casttypename std::remove_referenceT::type *(nullptr);
}
enum E { A, B };
int main() {
invalidE();
}
{code}
* See it
[jira] [Commented] (MESOS-3101) Standardize separation of Windows/Linux-specific OS code
[ https://issues.apache.org/jira/browse/MESOS-3101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14643313#comment-14643313 ] Joseph Wu commented on MESOS-3101: -- You could say that the review is where we are doing the work. We're standardizing a refactor, and iterating on the refactor by using ReviewBoard; such that the 50+ files that do eventually get changed (MESOS-3102, MESOS-3103) will be easier. This review only touches about 10 files. Once we're happy with the refactor, then we'll open it up for general review. Standardize separation of Windows/Linux-specific OS code Key: MESOS-3101 URL: https://issues.apache.org/jira/browse/MESOS-3101 Project: Mesos Issue Type: Task Components: stout Reporter: Joseph Wu Assignee: Joseph Wu Labels: mesosphere There are 50+ files that must be touched to separate OS-specific code. First, we will standardize the changes by using stout/abort.hpp as an example. The review/discussion can be found here: https://reviews.apache.org/r/36625/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3155) Add a containerizer and executor that simulate the launching of tasks.
[ https://issues.apache.org/jira/browse/MESOS-3155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14643379#comment-14643379 ] James Peach commented on MESOS-3155: Any more details about this? We have been discussing the need for this (calling it the null mslave). Add a containerizer and executor that simulate the launching of tasks. --- Key: MESOS-3155 URL: https://issues.apache.org/jira/browse/MESOS-3155 Project: Mesos Issue Type: Improvement Components: containerization, slave Reporter: Cody Roseborough Assignee: Cody Roseborough Priority: Minor This could have a user-defined configuration file. This would allow users to locally test frameworks against a large, simulated cluster using mesos-local. Other points of contact for this are: [~lukeleslie], [~derekchiang] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-3157) only perform batch resource allocations
James Peach created MESOS-3157:
--
Summary: only perform batch resource allocations
Key: MESOS-3157
URL: https://issues.apache.org/jira/browse/MESOS-3157
Project: Mesos
Issue Type: Bug
Components: allocation
Reporter: James Peach
Our deployment environments have a lot of churn, with many short-live
frameworks that often revive offers. Running the allocator takes a long time
(from seconds up to minutes).
In this situation, event-triggered allocation causes the event queue in the
allocator process to get very long, and the allocator effectively becomes
unresponsive (eg. a revive offers message takes too long to come to the head of
the queue).
We have been running a patch to remove all the event-triggered allocations and
only allocate from the batch task {{HierarchicalAllocatorProcess::batch}}. This
works great and really improves responsiveness.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-3157) only perform batch resource allocations
[
https://issues.apache.org/jira/browse/MESOS-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach reassigned MESOS-3157:
--
Assignee: James Peach
only perform batch resource allocations
---
Key: MESOS-3157
URL: https://issues.apache.org/jira/browse/MESOS-3157
Project: Mesos
Issue Type: Bug
Components: allocation
Reporter: James Peach
Assignee: James Peach
Our deployment environments have a lot of churn, with many short-live
frameworks that often revive offers. Running the allocator takes a long time
(from seconds up to minutes).
In this situation, event-triggered allocation causes the event queue in the
allocator process to get very long, and the allocator effectively becomes
unresponsive (eg. a revive offers message takes too long to come to the head
of the queue).
We have been running a patch to remove all the event-triggered allocations
and only allocate from the batch task
{{HierarchicalAllocatorProcess::batch}}. This works great and really improves
responsiveness.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-3155) Add a containerizer and executor that simulate the launching of tasks.
[ https://issues.apache.org/jira/browse/MESOS-3155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cody Roseborough updated MESOS-3155: Description: This could have a user-defined configuration file. This would allow users to locally test frameworks against a large, simulated cluster using mesos-local. Other points of contact for this are: [~lukeleslie], [~derekchiang] was: This could have a user-defined configuration file. This would allow users to locally test frameworks against a large, simulated cluster using mesos-local. Other points of contact for this are: Add a containerizer and executor that simulate the launching of tasks. --- Key: MESOS-3155 URL: https://issues.apache.org/jira/browse/MESOS-3155 Project: Mesos Issue Type: Improvement Components: containerization, slave Reporter: Cody Roseborough Assignee: Cody Roseborough Priority: Minor This could have a user-defined configuration file. This would allow users to locally test frameworks against a large, simulated cluster using mesos-local. Other points of contact for this are: [~lukeleslie], [~derekchiang] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3155) Add a containerizer and executor that simulate the launching of tasks.
[ https://issues.apache.org/jira/browse/MESOS-3155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cody Roseborough updated MESOS-3155: Description: This could have a user-defined configuration file. This would allow users to locally test frameworks against a large, simulated cluster using mesos-local. Other points of contact for this are: was:This could have a user-defined configuration file. This would allow users to locally test frameworks against a large, simulated cluster using mesos-local. Add a containerizer and executor that simulate the launching of tasks. --- Key: MESOS-3155 URL: https://issues.apache.org/jira/browse/MESOS-3155 Project: Mesos Issue Type: Improvement Components: containerization, slave Reporter: Cody Roseborough Assignee: Cody Roseborough Priority: Minor This could have a user-defined configuration file. This would allow users to locally test frameworks against a large, simulated cluster using mesos-local. Other points of contact for this are: -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-786) Update semantics of when framework registered()/reregistered() get called
[ https://issues.apache.org/jira/browse/MESOS-786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14643366#comment-14643366 ] Yan Xu commented on MESOS-786: -- This issue is (indirectly) fixed by MESOS-3088. Update semantics of when framework registered()/reregistered() get called - Key: MESOS-786 URL: https://issues.apache.org/jira/browse/MESOS-786 Project: Mesos Issue Type: Bug Reporter: Vinod Kone Assignee: Vinod Kone Current semantics: 1) Framework connects w/ master very first time -- registered() 2) Framework reconnects w/ same master after a zk blip -- reregistered() 3) Framework reconnects w/ failed over master -- registered() 4) Failed over framework connects w/ same master -- registered() 5) Failed over framework connects w/ failed over master -- registered() Updated semantics: Everything same except 3) Framework reconnects w/ failed over master -- reregistered() -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-3156) Inconsistency between mesos master UI and mesos slave /metrics/snapshot
Sebastian Otaegui created MESOS-3156:
Summary: Inconsistency between mesos master UI and mesos slave
/metrics/snapshot
Key: MESOS-3156
URL: https://issues.apache.org/jira/browse/MESOS-3156
Project: Mesos
Issue Type: Bug
Components: master, slave, statistics, webui
Affects Versions: 0.22.1
Environment: Test environment runs on vagrant
Master: Centos 7 + mesos 0.22.1 + marathon 0.9.0 = 1 vcpu + 1gb ram
Slave: Centos 7 + mesos 0.22.1 = 3vcpus + 2048mb
(1 master + 1 slave)
Reporter: Sebastian Otaegui
We recently began doing some tests with kibana to graph some of the stats of
the slaves and the masters.
We found something pretty odd:
Test case:
In my example my slave has 1840 mb free, of which mesos reserves 920mb for
tasks.
1. create N (in my case 14) marathon tasks with the following configuration
{noformat}
command: while true; do sleep 1 ; echo heloo; done
mem: 64mb
cpu: 0.1
{noformat}
2. check the mesos master web UI
{noformat}
Total 3 920 MB
Used1.4 896 MB
{noformat}
3. check the slave host:5051/metrics/snapshot
{noformat}
slave/mem_total:920,
slave/mem_used”:1344
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-2879) Random recursive_mutex errors in when running make check
[
https://issues.apache.org/jira/browse/MESOS-2879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joris Van Remoortere reassigned MESOS-2879:
---
Assignee: Joris Van Remoortere
Random recursive_mutex errors in when running make check
Key: MESOS-2879
URL: https://issues.apache.org/jira/browse/MESOS-2879
Project: Mesos
Issue Type: Bug
Reporter: Alexander Rojas
Assignee: Joris Van Remoortere
Labels: mesosphere, tech-debt
While running make check on OS X, from time to time {{recursive_mutex}}
errors appear after running all the test successfully. Just one of the
experience messages actually stops {{make check}} reporting an error.
The following error messages have been experienced:
{code}
libc++abi.dylib: libc++abi.dylib: libc++abi.dylib: libc++abi.dylib:
libc++abi.dylib: libc++abi.dylib: terminating with uncaught exception of type
std::__1::system_error: recursive_mutex lock failed: Invalid
argumentterminating with uncaught exception of type std::__1::system_error:
recursive_mutex lock failed: Invalid argumentterminating with uncaught
exception of type std::__1::system_error: recursive_mutex lock failed:
Invalid argumentterminating with uncaught exception of type
std::__1::system_error: recursive_mutex lock failed: Invalid
argumentterminating with uncaught exception of type std::__1::system_error:
recursive_mutex lock failed: Invalid argumentterminating with uncaught
exception of type std::__1::system_error: recursive_mutex lock failed:
Invalid argument
*** Aborted at 1434553937 (unix time) try date -d @1434553937 if you are
using GNU date ***
{code}
{code}
libc++abi.dylib: terminating with uncaught exception of type
std::__1::system_error: recursive_mutex lock failed: Invalid argument
*** Aborted at 1434557001 (unix time) try date -d @1434557001 if you are
using GNU date ***
libc++abi.dylib: PC: @ 0x7fff93855286 __pthread_kill
libc++abi.dylib: *** SIGABRT (@0x7fff93855286) received by PID 88060 (TID
0x10fc4) stack trace: ***
@ 0x7fff8e1d6f1a _sigtramp
libc++abi.dylib: @0x10fc3f1a8 (unknown)
libc++abi.dylib: @ 0x7fff979deb53 abort
libc++abi.dylib: libc++abi.dylib: libc++abi.dylib: terminating with uncaught
exception of type std::__1::system_error: recursive_mutex lock failed:
Invalid argumentterminating with uncaught exception of type
std::__1::system_error: recursive_mutex lock failed: Invalid
argumentterminating with uncaught exception of type std::__1::system_error:
recursive_mutex lock failed: Invalid argumentterminating with uncaught
exception of type std::__1::system_error: recursive_mutex lock failed:
Invalid argumentterminating with uncaught exception of type
std::__1::system_error: recursive_mutex lock failed: Invalid
argumentterminating with uncaught exception of type std::__1::system_error:
recursive_mutex lock failed: Invalid argumentMaking check in include
{code}
{code}
Assertion failed: (e == 0), function ~recursive_mutex, file
/SourceCache/libcxx/libcxx-120/src/mutex.cpp, line 82.
*** Aborted at 1434555685 (unix time) try date -d @1434555685 if you are
using GNU date ***
PC: @ 0x7fff93855286 __pthread_kill
*** SIGABRT (@0x7fff93855286) received by PID 60235 (TID 0x7fff7ebdc300)
stack trace: ***
@ 0x7fff8e1d6f1a _sigtramp
@0x10b512350 google::CheckNotNull()
@ 0x7fff979deb53 abort
@ 0x7fff979a6c39 __assert_rtn
@ 0x7fff9bffdcc9 std::__1::recursive_mutex::~recursive_mutex()
@0x10b881928 process::ProcessManager::~ProcessManager()
@0x10b874445 process::ProcessManager::~ProcessManager()
@0x10b874418 process::finalize()
@0x10b2f7aec main
@ 0x7fff98edc5c9 start
make[5]: *** [check-local] Abort trap: 6
make[4]: *** [check-am] Error 2
make[3]: *** [check-recursive] Error 1
make[2]: *** [check-recursive] Error 1
make[1]: *** [check] Error 2
make: *** [check-recursive] Error 1
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-3158) Libprocess Process: Join runqueue workers during finalization
Joris Van Remoortere created MESOS-3158: --- Summary: Libprocess Process: Join runqueue workers during finalization Key: MESOS-3158 URL: https://issues.apache.org/jira/browse/MESOS-3158 Project: Mesos Issue Type: Improvement Components: libprocess Reporter: Joris Van Remoortere The lack of synchronization between ProcessManager destruction and the thread pool threads running the queued processes means that the shared state that is part of the ProcessManager gets destroyed prematurely. Synchronizing the ProcessManager destructor with draining the work queues and stopping the workers will allow us to not require leaking the shared state to avoid use beyond destruction. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-786) Update semantics of when framework registered()/reregistered() get called
[ https://issues.apache.org/jira/browse/MESOS-786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14643366#comment-14643366 ] Yan Xu edited comment on MESOS-786 at 7/27/15 9:41 PM: --- Fixed by MESOS-3088 and MESOS-2910. was (Author: xujyan): This issue is (indirectly) fixed by MESOS-3088. Update semantics of when framework registered()/reregistered() get called - Key: MESOS-786 URL: https://issues.apache.org/jira/browse/MESOS-786 Project: Mesos Issue Type: Bug Reporter: Vinod Kone Assignee: Vinod Kone Current semantics: 1) Framework connects w/ master very first time -- registered() 2) Framework reconnects w/ same master after a zk blip -- reregistered() 3) Framework reconnects w/ failed over master -- registered() 4) Failed over framework connects w/ same master -- registered() 5) Failed over framework connects w/ failed over master -- registered() Updated semantics: Everything same except 3) Framework reconnects w/ failed over master -- reregistered() -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3156) Inconsistency between mesos master UI and mesos slave /metrics/snapshot
[
https://issues.apache.org/jira/browse/MESOS-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Otaegui updated MESOS-3156:
-
Description:
We recently began doing some tests with kibana to graph some of the stats of
the slaves and the masters.
We found something pretty odd:
Test case:
In my example my slave has 1840 mb free, of which mesos reserves 920mb for
tasks.
1. create N (in my case 14) marathon tasks with the following configuration
{noformat}
command: while true; do sleep 1 ; echo heloo; done
mem: 64mb
cpu: 0.1
{noformat}
2. check the mesos master web UI
{noformat}
Total 3 920 MB
Used1.4 896 MB
{noformat}
3. check the slave host:5051/metrics/snapshot
{noformat}
slave/mem_total:920,
slave/mem_used”:1344
{noformat}
Is this correct? I discussed this issue on the DCOS community slack channel
with Adam and he told me that the correct numbers are in the #3 he explained
that for each task, there are about 32mb + 0.1 cpu that is assigned to a
default executor.
I also changed the slave to enable cgroups_limit_swap:
{noformat}
/etc/mesos-slave/
├── attributes
├── cgroups_limit_swap
├── containerizers
├── executor_registration_timeout
├── hostname
├── isolation
├── resources
└── work_dir
{noformat}
{noformat}
cat /etc/mesos-slave/cgroups_limit_swap
true
{noformat}
{noformat}
ps ax | grep slave
26810 ?Ssl0:02 /usr/sbin/mesos-slave
--master=zk://172.41.5.11:2181/mesos --ip=172.41.6.11 --cgroups_limit_swap=true
--containerizers=docker,mesos --executor_registration_timeout=30mins
--hostname=172.41.6.11 --isolation=cgroups/cpu,cgroups/mem --work_dir=/tmp/mesos
{noformat}
was:
We recently began doing some tests with kibana to graph some of the stats of
the slaves and the masters.
We found something pretty odd:
Test case:
In my example my slave has 1840 mb free, of which mesos reserves 920mb for
tasks.
1. create N (in my case 14) marathon tasks with the following configuration
{noformat}
command: while true; do sleep 1 ; echo heloo; done
mem: 64mb
cpu: 0.1
{noformat}
2. check the mesos master web UI
{noformat}
Total 3 920 MB
Used1.4 896 MB
{noformat}
3. check the slave host:5051/metrics/snapshot
{noformat}
slave/mem_total:920,
slave/mem_used”:1344
{noformat}
Inconsistency between mesos master UI and mesos slave /metrics/snapshot
---
Key: MESOS-3156
URL: https://issues.apache.org/jira/browse/MESOS-3156
Project: Mesos
Issue Type: Bug
Components: master, slave, statistics, webui
Affects Versions: 0.22.1
Environment: Test environment runs on vagrant
Master: Centos 7 + mesos 0.22.1 + marathon 0.9.0 = 1 vcpu + 1gb ram
Slave: Centos 7 + mesos 0.22.1 = 3vcpus + 2048mb
(1 master + 1 slave)
Reporter: Sebastian Otaegui
We recently began doing some tests with kibana to graph some of the stats of
the slaves and the masters.
We found something pretty odd:
Test case:
In my example my slave has 1840 mb free, of which mesos reserves 920mb for
tasks.
1. create N (in my case 14) marathon tasks with the following configuration
{noformat}
command: while true; do sleep 1 ; echo heloo; done
mem: 64mb
cpu: 0.1
{noformat}
2. check the mesos master web UI
{noformat}
Total 3 920 MB
Used 1.4 896 MB
{noformat}
3. check the slave host:5051/metrics/snapshot
{noformat}
slave/mem_total:920,
slave/mem_used”:1344
{noformat}
Is this correct? I discussed this issue on the DCOS community slack channel
with Adam and he told me that the correct numbers are in the #3 he explained
that for each task, there are about 32mb + 0.1 cpu that is assigned to a
default executor.
I also changed the slave to enable cgroups_limit_swap:
{noformat}
/etc/mesos-slave/
├── attributes
├── cgroups_limit_swap
├── containerizers
├── executor_registration_timeout
├── hostname
├── isolation
├── resources
└── work_dir
{noformat}
{noformat}
cat /etc/mesos-slave/cgroups_limit_swap
true
{noformat}
{noformat}
ps ax | grep slave
26810 ?Ssl0:02 /usr/sbin/mesos-slave
--master=zk://172.41.5.11:2181/mesos --ip=172.41.6.11
--cgroups_limit_swap=true --containerizers=docker,mesos
--executor_registration_timeout=30mins --hostname=172.41.6.11
--isolation=cgroups/cpu,cgroups/mem --work_dir=/tmp/mesos
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3157) only perform batch resource allocations
[
https://issues.apache.org/jira/browse/MESOS-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14643395#comment-14643395
]
James Peach commented on MESOS-3157:
I can post a patch for this. I need a shepherd and advice on whether this
should be a configuration option, or whether the event-triggered allocation
should just be removed.
only perform batch resource allocations
---
Key: MESOS-3157
URL: https://issues.apache.org/jira/browse/MESOS-3157
Project: Mesos
Issue Type: Bug
Components: allocation
Reporter: James Peach
Assignee: James Peach
Our deployment environments have a lot of churn, with many short-live
frameworks that often revive offers. Running the allocator takes a long time
(from seconds up to minutes).
In this situation, event-triggered allocation causes the event queue in the
allocator process to get very long, and the allocator effectively becomes
unresponsive (eg. a revive offers message takes too long to come to the head
of the queue).
We have been running a patch to remove all the event-triggered allocations
and only allocate from the batch task
{{HierarchicalAllocatorProcess::batch}}. This works great and really improves
responsiveness.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-2879) Random recursive_mutex errors in when running make check
[
https://issues.apache.org/jira/browse/MESOS-2879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joris Van Remoortere updated MESOS-2879:
Shepherd: Benjamin Hindman
Sprint: Mesosphere Sprint 15
Story Points: 1
Component/s: libprocess
Random recursive_mutex errors in when running make check
Key: MESOS-2879
URL: https://issues.apache.org/jira/browse/MESOS-2879
Project: Mesos
Issue Type: Bug
Components: libprocess
Reporter: Alexander Rojas
Assignee: Joris Van Remoortere
Labels: mesosphere, tech-debt
While running make check on OS X, from time to time {{recursive_mutex}}
errors appear after running all the test successfully. Just one of the
experience messages actually stops {{make check}} reporting an error.
The following error messages have been experienced:
{code}
libc++abi.dylib: libc++abi.dylib: libc++abi.dylib: libc++abi.dylib:
libc++abi.dylib: libc++abi.dylib: terminating with uncaught exception of type
std::__1::system_error: recursive_mutex lock failed: Invalid
argumentterminating with uncaught exception of type std::__1::system_error:
recursive_mutex lock failed: Invalid argumentterminating with uncaught
exception of type std::__1::system_error: recursive_mutex lock failed:
Invalid argumentterminating with uncaught exception of type
std::__1::system_error: recursive_mutex lock failed: Invalid
argumentterminating with uncaught exception of type std::__1::system_error:
recursive_mutex lock failed: Invalid argumentterminating with uncaught
exception of type std::__1::system_error: recursive_mutex lock failed:
Invalid argument
*** Aborted at 1434553937 (unix time) try date -d @1434553937 if you are
using GNU date ***
{code}
{code}
libc++abi.dylib: terminating with uncaught exception of type
std::__1::system_error: recursive_mutex lock failed: Invalid argument
*** Aborted at 1434557001 (unix time) try date -d @1434557001 if you are
using GNU date ***
libc++abi.dylib: PC: @ 0x7fff93855286 __pthread_kill
libc++abi.dylib: *** SIGABRT (@0x7fff93855286) received by PID 88060 (TID
0x10fc4) stack trace: ***
@ 0x7fff8e1d6f1a _sigtramp
libc++abi.dylib: @0x10fc3f1a8 (unknown)
libc++abi.dylib: @ 0x7fff979deb53 abort
libc++abi.dylib: libc++abi.dylib: libc++abi.dylib: terminating with uncaught
exception of type std::__1::system_error: recursive_mutex lock failed:
Invalid argumentterminating with uncaught exception of type
std::__1::system_error: recursive_mutex lock failed: Invalid
argumentterminating with uncaught exception of type std::__1::system_error:
recursive_mutex lock failed: Invalid argumentterminating with uncaught
exception of type std::__1::system_error: recursive_mutex lock failed:
Invalid argumentterminating with uncaught exception of type
std::__1::system_error: recursive_mutex lock failed: Invalid
argumentterminating with uncaught exception of type std::__1::system_error:
recursive_mutex lock failed: Invalid argumentMaking check in include
{code}
{code}
Assertion failed: (e == 0), function ~recursive_mutex, file
/SourceCache/libcxx/libcxx-120/src/mutex.cpp, line 82.
*** Aborted at 1434555685 (unix time) try date -d @1434555685 if you are
using GNU date ***
PC: @ 0x7fff93855286 __pthread_kill
*** SIGABRT (@0x7fff93855286) received by PID 60235 (TID 0x7fff7ebdc300)
stack trace: ***
@ 0x7fff8e1d6f1a _sigtramp
@0x10b512350 google::CheckNotNull()
@ 0x7fff979deb53 abort
@ 0x7fff979a6c39 __assert_rtn
@ 0x7fff9bffdcc9 std::__1::recursive_mutex::~recursive_mutex()
@0x10b881928 process::ProcessManager::~ProcessManager()
@0x10b874445 process::ProcessManager::~ProcessManager()
@0x10b874418 process::finalize()
@0x10b2f7aec main
@ 0x7fff98edc5c9 start
make[5]: *** [check-local] Abort trap: 6
make[4]: *** [check-am] Error 2
make[3]: *** [check-recursive] Error 1
make[2]: *** [check-recursive] Error 1
make[1]: *** [check] Error 2
make: *** [check-recursive] Error 1
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-3141) Compiler warning when mocking function type has an enum return type.
[
https://issues.apache.org/jira/browse/MESOS-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Park updated MESOS-3141:
Description:
The purpose of this ticket is to document a very cryptic error message
(actually a warning that gets propagated by {{-Werror}}) that gets generated by
{{clang-3.5}} from {{gmock}} source code when trying to mock a perfectly
innocent-looking function.
h3. Problem
The following code is attempting to mock a {{MesosExecutorDriver}}:
{code}
class MockMesosExecutorDriver : public MesosExecutorDriver {
public:
MockMesosExecutorDriver(mesos::Executor* executor)
: MesosExecutorDriver(executor) {}
MOCK_METHOD1(sendStatusUpdate, Status(const TaskStatus));
};
{code}
The above code generates the following error message:
{noformat}
In file included from
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock.h:58:
In file included from
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:46:
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h:355:10:
error: indirection of non-volatile null pointer will be deleted, not trap
[-Werror,-Wnull-dereference]
return *static_casttypename remove_referenceT::type*(__null);
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:78:22:
note: in instantiation of function template specialization
'testing::internal::Invalidmesos::Status' requested here
return internal::InvalidT();
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:190:43:
note: in instantiation of member function
'testing::internal::BuiltInDefaultValuemesos::Status::Get' requested here
internal::BuiltInDefaultValueT::Get() : *value_;
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1435:34:
note: in instantiation of member function
'testing::DefaultValuemesos::Status::Get' requested here
return DefaultValueResult::Get();
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1334:22:
note: in instantiation of member function
'testing::internal::FunctionMockerBasemesos::Status (const mesos::TaskStatus
)::PerformDefaultAction' requested here
func_mocker-PerformDefaultAction(args, call_description));
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1448:26:
note: in instantiation of function template specialization
'testing::internal::ActionResultHoldermesos::Status::PerformDefaultActionmesos::Status
(const mesos::TaskStatus )' requested here
return ResultHolder::PerformDefaultAction(this, args, call_description);
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-generated-function-mockers.h:81:7:
note: in instantiation of member function
'testing::internal::FunctionMockerBasemesos::Status (const mesos::TaskStatus
)::UntypedPerformDefaultAction' requested here
class FunctionMockerR(A1) : public
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h:355:10:
note: consider using __builtin_trap() or qualifying pointer with 'volatile'
return *static_casttypename remove_referenceT::type*(__null);
^
{noformat}
The source of the issue here is that {{Status}} is an {{enum}}. In
{{gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h}} you can find the
following function:
{code}
template typename T
T Invalid() {
return *static_casttypename remove_referenceT::type*(NULL);
}
{code}
This function gets called with the return type of a mocked function. In our
case, the return type of the mocked function is {{Status}}.
Attempting to compile the following minimal example with {{clang-3.5}}
reproduces the error message:
{code}
#include type_traits
template typename T
T invalid() {
return *static_casttypename std::remove_referenceT::type *(nullptr);
}
enum E { A, B };
int main() {
invalidE();
}
{code}
* See it online on [GCC Explorer|https://goo.gl/t1FepZ]
Note that if the type is not an {{enum}}, the warning is not generated. This is
why existing mocked functions that return non-{{enum}} types such as
{{Futurevoid}} does not encounter this issue.
h3. Solutions
The simplest solution is to add {{-Wno-null-deference}} to
{{mesos_tests_CPPFLAGS}} in {{src/Makefile.am}}.
{code}
mesos_tests_CPPFLAGS = $(MESOS_CPPFLAGS) -Wno-null-dereference
{code}
Another solution is to upgrade {{gmock}} from *1.6* to *1.7* to as I believe
this problem is solved in the newer versions.
was:
The purpose of this ticket is to document a very cryptic error message
(actually a warning that gets propagated by {{-Werror}}) that gets generated by
{{clang-3.5}} from {{gmock}} source
[jira] [Commented] (MESOS-3141) Compiler warning when mocking function type has an enum return type.
[
https://issues.apache.org/jira/browse/MESOS-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14643545#comment-14643545
]
Michael Park commented on MESOS-3141:
-
CC [~derekchiang]
Compiler warning when mocking function type has an enum return type.
Key: MESOS-3141
URL: https://issues.apache.org/jira/browse/MESOS-3141
Project: Mesos
Issue Type: Bug
Affects Versions: 0.23.0
Reporter: Michael Park
Assignee: haosdent
Labels: mesosphere
The purpose of this ticket is to document a very cryptic error message
(actually a warning that gets propagated by {{-Werror}}) that gets generated
by {{clang-3.5}} from {{gmock}} source code when trying to mock a perfectly
innocent-looking function.
h3. Problem
The following code is attempting to mock a {{MesosExecutorDriver}}:
{code}
class MockMesosExecutorDriver : public MesosExecutorDriver {
public:
MockMesosExecutorDriver(mesos::Executor* executor)
: MesosExecutorDriver(executor) {}
MOCK_METHOD1(sendStatusUpdate, Status(const TaskStatus));
};
{code}
The above code generates the following error message:
{noformat}
In file included from
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock.h:58:
In file included from
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:46:
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h:355:10:
error: indirection of non-volatile null pointer will be deleted, not trap
[-Werror,-Wnull-dereference]
return *static_casttypename remove_referenceT::type*(__null);
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:78:22:
note: in instantiation of function template specialization
'testing::internal::Invalidmesos::Status' requested here
return internal::InvalidT();
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:190:43:
note: in instantiation of member function
'testing::internal::BuiltInDefaultValuemesos::Status::Get' requested here
internal::BuiltInDefaultValueT::Get() : *value_;
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1435:34:
note: in instantiation of member function
'testing::DefaultValuemesos::Status::Get' requested here
return DefaultValueResult::Get();
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1334:22:
note: in instantiation of member function
'testing::internal::FunctionMockerBasemesos::Status (const mesos::TaskStatus
)::PerformDefaultAction' requested here
func_mocker-PerformDefaultAction(args, call_description));
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1448:26:
note: in instantiation of function template specialization
'testing::internal::ActionResultHoldermesos::Status::PerformDefaultActionmesos::Status
(const mesos::TaskStatus )' requested here
return ResultHolder::PerformDefaultAction(this, args, call_description);
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-generated-function-mockers.h:81:7:
note: in instantiation of member function
'testing::internal::FunctionMockerBasemesos::Status (const mesos::TaskStatus
)::UntypedPerformDefaultAction' requested here
class FunctionMockerR(A1) : public
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h:355:10:
note: consider using __builtin_trap() or qualifying pointer with 'volatile'
return *static_casttypename remove_referenceT::type*(__null);
^
{noformat}
The source of the issue here is that {{Status}} is an {{enum}}. In
{{gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h}} you can find
the following function:
{code}
template typename T
T Invalid() {
return *static_casttypename remove_referenceT::type*(NULL);
}
{code}
This function gets called with the return type of a mocked function. In our
case, the return type of the mocked function is {{Status}}.
Attempting to compile the following minimal example with {{clang-3.5}}
reproduces the error message:
{code}
#include type_traits
template typename T
T invalid() {
return *static_casttypename std::remove_referenceT::type *(nullptr);
}
enum E { A, B };
int main() {
invalidE();
}
{code}
* See it online on [GCC Explorer|https://goo.gl/t1FepZ]
Note that if the type is not an {{enum}}, the warning is not generated. This
is why existing mocked functions that return non-{{enum}} types such as
[jira] [Created] (MESOS-3159) Add metrics counter for preempted executors (due to QoS corrections)
Niklas Quarfot Nielsen created MESOS-3159: - Summary: Add metrics counter for preempted executors (due to QoS corrections) Key: MESOS-3159 URL: https://issues.apache.org/jira/browse/MESOS-3159 Project: Mesos Issue Type: Improvement Reporter: Niklas Quarfot Nielsen We should keep track of how many containers/executors has been destroyed/killed due to preemption (due to QoS corrections). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3159) Add metrics counter for preempted executors (due to QoS corrections)
[ https://issues.apache.org/jira/browse/MESOS-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14643493#comment-14643493 ] Niklas Quarfot Nielsen commented on MESOS-3159: --- [~jieyu] Does this make sense? And if so, can I get you to shepherd? Add metrics counter for preempted executors (due to QoS corrections) Key: MESOS-3159 URL: https://issues.apache.org/jira/browse/MESOS-3159 Project: Mesos Issue Type: Improvement Reporter: Niklas Quarfot Nielsen We should keep track of how many containers/executors has been destroyed/killed due to preemption (due to QoS corrections). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3103) Separate OS-specific code in the libprocess library
[
https://issues.apache.org/jira/browse/MESOS-3103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Wu updated MESOS-3103:
-
Assignee: Alex Clemmer (was: Joseph Wu)
Separate OS-specific code in the libprocess library
---
Key: MESOS-3103
URL: https://issues.apache.org/jira/browse/MESOS-3103
Project: Mesos
Issue Type: Task
Components: libprocess
Reporter: Joseph Wu
Assignee: Alex Clemmer
Labels: mesosphere
This issue tracks changes for all files under
{{3rdparty/libprocess/include/}} and {{3rdparty/libprocess/src}}.
The changes will be based on this commit:
https://github.com/hausdorff/mesos/commit/b862f66c6ff58c115a009513621e5128cb734d52#diff-a6d038bad64b154996452bec020cfa7c
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3155) Add a containerizer and executor that simulate the launching of tasks.
[ https://issues.apache.org/jira/browse/MESOS-3155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14643535#comment-14643535 ] Cody Roseborough commented on MESOS-3155: - Added more details to the description. I'd be interested to know what sorts of things you have discussed related to this. Add a containerizer and executor that simulate the launching of tasks. --- Key: MESOS-3155 URL: https://issues.apache.org/jira/browse/MESOS-3155 Project: Mesos Issue Type: Improvement Components: containerization, slave Reporter: Cody Roseborough Assignee: Cody Roseborough Priority: Minor This could have a user-defined configuration file. This would allow users to locally test frameworks against a large, simulated cluster using mesos-local. The Simulator Containerizer (SC) is a containerizer that can be used in conjunction with mesos-local to exercise frameworks at a large scale without launching a large cluster. The SC launches a fake executor instead of the one specified by the tasks, in order to avoid using actual resources. The SC provides normal tasks updates as well as configurable task options via a configuration JSON file. Some of the options available for configuration might be length or failure rate. Other points of contact for this are: [~lukeleslie], [~derekchiang] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-3160) CgroupsAnyHierarchyMemoryPressureTest.ROOT_IncreaseUnlockedRSS Flaky
Paul Brett created MESOS-3160: - Summary: CgroupsAnyHierarchyMemoryPressureTest.ROOT_IncreaseUnlockedRSS Flaky Key: MESOS-3160 URL: https://issues.apache.org/jira/browse/MESOS-3160 Project: Mesos Issue Type: Bug Affects Versions: 0.24.0 Reporter: Paul Brett Test will occasionally with: [ RUN ] CgroupsAnyHierarchyMemoryPressureTest.ROOT_IncreaseUnlockedRSS ../../src/tests/containerizer/cgroups_tests.cpp:1103: Failure helper.increaseRSS(getpagesize()): Failed to sync with the subprocess ../../src/tests/containerizer/cgroups_tests.cpp:1103: Failure helper.increaseRSS(getpagesize()): The subprocess has not been spawned yet [ FAILED ] CgroupsAnyHierarchyMemoryPressureTest.ROOT_IncreaseUnlockedRSS (223 ms) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3155) Add a containerizer and executor that simulate the launching of tasks.
[ https://issues.apache.org/jira/browse/MESOS-3155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cody Roseborough updated MESOS-3155: Description: This could have a user-defined configuration file. This would allow users to locally test frameworks against a large, simulated cluster using mesos-local. The Simulator Containerizer (SC) is a containerizer that can be used in conjunction with mesos-local to exercise frameworks at a large scale without launching a large cluster. The SC launches a fake executor instead of the one specified by the tasks, in order to avoid using actual resources. The SC provides normal tasks updates as well as configurable task options via a configuration JSON file. Some of the options available for configuration might be length or failure rate. Other points of contact for this are: [~lukeleslie], [~derekchiang] was: This could have a user-defined configuration file. This would allow users to locally test frameworks against a large, simulated cluster using mesos-local. Other points of contact for this are: [~lukeleslie], [~derekchiang] Add a containerizer and executor that simulate the launching of tasks. --- Key: MESOS-3155 URL: https://issues.apache.org/jira/browse/MESOS-3155 Project: Mesos Issue Type: Improvement Components: containerization, slave Reporter: Cody Roseborough Assignee: Cody Roseborough Priority: Minor This could have a user-defined configuration file. This would allow users to locally test frameworks against a large, simulated cluster using mesos-local. The Simulator Containerizer (SC) is a containerizer that can be used in conjunction with mesos-local to exercise frameworks at a large scale without launching a large cluster. The SC launches a fake executor instead of the one specified by the tasks, in order to avoid using actual resources. The SC provides normal tasks updates as well as configurable task options via a configuration JSON file. Some of the options available for configuration might be length or failure rate. Other points of contact for this are: [~lukeleslie], [~derekchiang] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3155) Add a containerizer and executor that simulate the launching of tasks.
[ https://issues.apache.org/jira/browse/MESOS-3155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cody Roseborough updated MESOS-3155: Description: The Simulator Containerizer (SC) is a containerizer that can be used in conjunction with mesos-local to exercise frameworks at a large scale without launching a large cluster. The SC launches a fake executor instead of the one specified by the tasks, in order to avoid using actual resources. The SC provides normal tasks updates as well as configurable task options via a configuration JSON file. Some of the options available for configuration might be length or failure rate. Other points of contact for this are: [~lukeleslie], [~derekchiang] was: This could have a user-defined configuration file. This would allow users to locally test frameworks against a large, simulated cluster using mesos-local. The Simulator Containerizer (SC) is a containerizer that can be used in conjunction with mesos-local to exercise frameworks at a large scale without launching a large cluster. The SC launches a fake executor instead of the one specified by the tasks, in order to avoid using actual resources. The SC provides normal tasks updates as well as configurable task options via a configuration JSON file. Some of the options available for configuration might be length or failure rate. Other points of contact for this are: [~lukeleslie], [~derekchiang] Add a containerizer and executor that simulate the launching of tasks. --- Key: MESOS-3155 URL: https://issues.apache.org/jira/browse/MESOS-3155 Project: Mesos Issue Type: Improvement Components: containerization, slave Reporter: Cody Roseborough Assignee: Cody Roseborough Priority: Minor The Simulator Containerizer (SC) is a containerizer that can be used in conjunction with mesos-local to exercise frameworks at a large scale without launching a large cluster. The SC launches a fake executor instead of the one specified by the tasks, in order to avoid using actual resources. The SC provides normal tasks updates as well as configurable task options via a configuration JSON file. Some of the options available for configuration might be length or failure rate. Other points of contact for this are: [~lukeleslie], [~derekchiang] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-2757) Can't Use - operator with OptionT, TryT, ResultT, FutureT
[ https://issues.apache.org/jira/browse/MESOS-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Mahler reassigned MESOS-2757: -- Assignee: Benjamin Mahler (was: Joris Van Remoortere) Can't Use - operator with OptionT, TryT, ResultT, FutureT -- Key: MESOS-2757 URL: https://issues.apache.org/jira/browse/MESOS-2757 Project: Mesos Issue Type: Improvement Components: stout Reporter: Joris Van Remoortere Assignee: Benjamin Mahler Labels: c++11, mesosphere, option, stout Let's add operator overloads to OptionT to allow access to the underlying T using the `-` operator. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-3151) Reservation Test failed
[
https://issues.apache.org/jira/browse/MESOS-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jihun Kang reassigned MESOS-3151:
-
Assignee: Jihun Kang
Reservation Test failed
---
Key: MESOS-3151
URL: https://issues.apache.org/jira/browse/MESOS-3151
Project: Mesos
Issue Type: Bug
Environment: Ubuntu 14.04.2
IBM JDK 1.7.0 SR8
Reporter: Jihun Kang
Assignee: Jihun Kang
Here is the details.
{noformat}
[ RUN ]
ReservationTest.CompatibleCheckpointedResourcesWithPersistentVolumes
../../src/tests/reservation_tests.cpp:1055: Failure
Value of: Resources(offer.resources()).contains(unreserved + unreservedDisk)
Actual: false
Expected: true
2015-07-27
17:31:16,280:9247(0x2ae20f41d700):ZOO_ERROR@handle_socket_error_msg@1697:
Socket [127.0.0.1:33182] zk retcode=-4, errno=111(Connection refused): server
refused to accept the client
2015-07-27
17:31:19,617:9247(0x2ae20f41d700):ZOO_ERROR@handle_socket_error_msg@1697:
Socket [127.0.0.1:33182] zk retcode=-4, errno=111(Connection refused): server
refused to accept the client
2015-07-27
17:31:22,951:9247(0x2ae20f41d700):ZOO_ERROR@handle_socket_error_msg@1697:
Socket [127.0.0.1:33182] zk retcode=-4, errno=111(Connection refused): server
refused to accept the client
2015-07-27
17:31:26,288:9247(0x2ae20f41d700):ZOO_ERROR@handle_socket_error_msg@1697:
Socket [127.0.0.1:33182] zk retcode=-4, errno=111(Connection refused): server
refused to accept the client
../../src/tests/reservation_tests.cpp:1076: Failure
Failed to wait 15secs for message1
*** Aborted at 1437985889 (unix time) try date -d @1437985889 if you are
using GNU date ***
PC: @0x0 (unknown)
../../3rdparty/libprocess/include/process/gmock.hpp:365: Failure
Actual function call count doesn't match EXPECT_CALL(filter-mock,
filter(testing::Aconst MessageEvent()))...
Expected args: message matcher (8-byte object C8-39 03-04 E2-2A 00-00,
1-byte object 61, 1-byte object E6)
Expected: to be called once
Actual: never called - unsatisfied and active
../../3rdparty/libprocess/include/process/gmock.hpp:365: Failure
Actual function call count doesn't match EXPECT_CALL(filter-mock,
filter(testing::Aconst MessageEvent()))...
Expected args: message matcher (8-byte object C8-39 03-04 E2-2A 00-00,
1-byte object 61, 1-byte object E6)
Expected: to be called once
Actual: never called - unsatisfied and active
[ FAILED ]
ReservationTest.CompatibleCheckpointedResourcesWithPersistentVolumes (15354
ms)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-2757) Add - operator for OptionT, TryT, ResultT, FutureT.
[ https://issues.apache.org/jira/browse/MESOS-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Mahler updated MESOS-2757: --- Sprint: Twitter Mesos Q3 Sprint 2 Add - operator for OptionT, TryT, ResultT, FutureT. Key: MESOS-2757 URL: https://issues.apache.org/jira/browse/MESOS-2757 Project: Mesos Issue Type: Improvement Components: libprocess, stout Reporter: Joris Van Remoortere Assignee: Benjamin Mahler Labels: c++11, mesosphere, option, stout, twitter Let's add operator overloads to OptionT to allow access to the underlying T using the `-` operator. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-3162) Provide a means to check http connection equality for streaming connections.
Benjamin Mahler created MESOS-3162: -- Summary: Provide a means to check http connection equality for streaming connections. Key: MESOS-3162 URL: https://issues.apache.org/jira/browse/MESOS-3162 Project: Mesos Issue Type: Task Components: libprocess Reporter: Benjamin Mahler Assignee: Benjamin Mahler If one uses an http::Pipe::Writer to stream a response, one cannot compare the writer with another to see if the connection has changed. This is useful for example, in the master's http api when there is asynchronous disconnection logic. When we handle the disconnection, it's possible for the scheduler to have re-subscribed, and so the master needs to tell if the disconnection event is relevant for the current connection before taking action. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3161) Document using the gold linker for faster development on linux.
[
https://issues.apache.org/jira/browse/MESOS-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Mahler updated MESOS-3161:
---
Description:
The [gold linker|https://en.wikipedia.org/wiki/Gold_(linker)] seems to provide
a decent speedup (about ~20%) on a parallel build. From a quick test:
{noformat: title=timings for make check -j24 GTEST_FILTER= w/ 24
hyperthreaded cores}
gold:
real7m18.526s
user81m21.213s
sys 5m17.224s
default ld:
real9m7.908s
user85m13.466s
sys 5m52.199s
{noformat}
On CentOS 5 w/ devtoolset-2:
{noformat}
sudo /usr/sbin/alternatives --altdir /opt/rh/devtoolset-2/root/etc/alternatives
--admindir /opt/rh/devtoolset-2/root/var/lib/alternatives --set ld
/opt/rh/devtoolset-2/root/usr/bin/ld.gold
{noformat}
Ideally we could this out on the website, with instructions for each OS.
was:
The [gold linker|https://en.wikipedia.org/wiki/Gold_(linker)] seems to provide
a decent speedup (about ~20%) on a parallel build. From a quick test:
{noformat: title=timings for make check -j24 w/ 24 hyperthreaded cores}
gold:
real7m18.526s
user81m21.213s
sys 5m17.224s
default ld:
real9m7.908s
user85m13.466s
sys 5m52.199s
{noformat}
On CentOS 5 w/ devtoolset-2:
{noformat}
sudo /usr/sbin/alternatives --altdir /opt/rh/devtoolset-2/root/etc/alternatives
--admindir /opt/rh/devtoolset-2/root/var/lib/alternatives --set ld
/opt/rh/devtoolset-2/root/usr/bin/ld.gold
{noformat}
Ideally we could this out on the website, with instructions for each OS.
Document using the gold linker for faster development on linux.
---
Key: MESOS-3161
URL: https://issues.apache.org/jira/browse/MESOS-3161
Project: Mesos
Issue Type: Improvement
Components: build, documentation
Reporter: Benjamin Mahler
Labels: newbie
The [gold linker|https://en.wikipedia.org/wiki/Gold_(linker)] seems to
provide a decent speedup (about ~20%) on a parallel build. From a quick test:
{noformat: title=timings for make check -j24 GTEST_FILTER= w/ 24
hyperthreaded cores}
gold:
real 7m18.526s
user 81m21.213s
sys 5m17.224s
default ld:
real 9m7.908s
user 85m13.466s
sys 5m52.199s
{noformat}
On CentOS 5 w/ devtoolset-2:
{noformat}
sudo /usr/sbin/alternatives --altdir
/opt/rh/devtoolset-2/root/etc/alternatives --admindir
/opt/rh/devtoolset-2/root/var/lib/alternatives --set ld
/opt/rh/devtoolset-2/root/usr/bin/ld.gold
{noformat}
Ideally we could this out on the website, with instructions for each OS.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3144) Update Homebrew formula for Mesos (Mac OSX)
[
https://issues.apache.org/jira/browse/MESOS-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14643754#comment-14643754
]
haosdent commented on MESOS-3144:
-
Yes, only need update sha256 in your pull request.
Update Homebrew formula for Mesos (Mac OSX)
---
Key: MESOS-3144
URL: https://issues.apache.org/jira/browse/MESOS-3144
Project: Mesos
Issue Type: Task
Reporter: Marco Massenzio
Assignee: Marco Massenzio
Priority: Trivial
Labels: mesosphere, newbie
We have pushed a [pull
request|https://github.com/Homebrew/homebrew/pull/42099] to Homebrew for the
new 0.23 formula.
Once accepted, we must verify that this works on a Mac OSX device.
This would also be a great time to ensure our documentation is up-to-date.
Currently, the Homebrew check fails, as they have deprecated SHA-1 checksums:
{noformat}
Error Message
failed: brew audit mesos
Stacktrace
Error: 7 problems in 1 formula
mesos:
* Stable resource protobuf: SHA1 checksums are deprecated, please use
SHA256
* Stable resource python-gflags: SHA1 checksums are deprecated, please use
SHA256
* Stable resource six: SHA1 checksums are deprecated, please use SHA256
* Stable resource google-apputils: SHA1 checksums are deprecated, please
use SHA256
* Stable resource python-dateutil: SHA1 checksums are deprecated, please
use SHA256
* Stable resource boto: SHA1 checksums are deprecated, please use SHA256
* Stable resource pytz: SHA1 checksums are deprecated, please use SHA256
{noformat}
Don't know enough about Homebrew to really figure out what is going on here;
nor how to fix this.
The Mesos SHA-256 has been correctly entered and computed via the [Online
SHA/MD5 calculator|https://md5file.com/calculator].
I guess, we should go download the packages and compute their SHA-256 and/or
research from the respective download sites whether they publish the SHA.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3141) Compiler warning when mocking function type has an enum return type.
[
https://issues.apache.org/jira/browse/MESOS-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14643768#comment-14643768
]
haosdent commented on MESOS-3141:
-
[~mcypark] Seems rbt use git diff to generate patch, and git diff don't
contains binary data change.
Compiler warning when mocking function type has an enum return type.
Key: MESOS-3141
URL: https://issues.apache.org/jira/browse/MESOS-3141
Project: Mesos
Issue Type: Bug
Affects Versions: 0.23.0
Reporter: Michael Park
Assignee: haosdent
Labels: mesosphere
The purpose of this ticket is to document a very cryptic error message
(actually a warning that gets propagated by {{-Werror}}) that gets generated
by {{clang-3.5}} from {{gmock}} source code when trying to mock a perfectly
innocent-looking function.
h3. Problem
The following code is attempting to mock a {{MesosExecutorDriver}}:
{code}
class MockMesosExecutorDriver : public MesosExecutorDriver {
public:
MockMesosExecutorDriver(mesos::Executor* executor)
: MesosExecutorDriver(executor) {}
MOCK_METHOD1(sendStatusUpdate, Status(const TaskStatus));
};
{code}
The above code generates the following error message:
{noformat}
In file included from
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock.h:58:
In file included from
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:46:
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h:355:10:
error: indirection of non-volatile null pointer will be deleted, not trap
[-Werror,-Wnull-dereference]
return *static_casttypename remove_referenceT::type*(__null);
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:78:22:
note: in instantiation of function template specialization
'testing::internal::Invalidmesos::Status' requested here
return internal::InvalidT();
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-actions.h:190:43:
note: in instantiation of member function
'testing::internal::BuiltInDefaultValuemesos::Status::Get' requested here
internal::BuiltInDefaultValueT::Get() : *value_;
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1435:34:
note: in instantiation of member function
'testing::DefaultValuemesos::Status::Get' requested here
return DefaultValueResult::Get();
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1334:22:
note: in instantiation of member function
'testing::internal::FunctionMockerBasemesos::Status (const mesos::TaskStatus
)::PerformDefaultAction' requested here
func_mocker-PerformDefaultAction(args, call_description));
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-spec-builders.h:1448:26:
note: in instantiation of function template specialization
'testing::internal::ActionResultHoldermesos::Status::PerformDefaultActionmesos::Status
(const mesos::TaskStatus )' requested here
return ResultHolder::PerformDefaultAction(this, args, call_description);
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/gmock-generated-function-mockers.h:81:7:
note: in instantiation of member function
'testing::internal::FunctionMockerBasemesos::Status (const mesos::TaskStatus
)::UntypedPerformDefaultAction' requested here
class FunctionMockerR(A1) : public
^
../3rdparty/libprocess/3rdparty/gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h:355:10:
note: consider using __builtin_trap() or qualifying pointer with 'volatile'
return *static_casttypename remove_referenceT::type*(__null);
^
{noformat}
The source of the issue here is that {{Status}} is an {{enum}}. In
{{gmock-1.6.0/include/gmock/internal/gmock-internal-utils.h}} you can find
the following function:
{code}
template typename T
T Invalid() {
return *static_casttypename remove_referenceT::type*(NULL);
}
{code}
This function gets called with the return type of a mocked function. In our
case, the return type of the mocked function is {{Status}}.
Attempting to compile the following minimal example with {{clang-3.5}}
reproduces the error message:
{code}
#include type_traits
template typename T
T invalid() {
return *static_casttypename std::remove_referenceT::type *(nullptr);
}
enum E { A, B };
int main() {
invalidE();
}
{code}
* See it online on [GCC Explorer|https://goo.gl/t1FepZ]
Note that if the type is not an {{enum}}, the warning is not generated. This
is why
[jira] [Created] (MESOS-3161) Document using the gold linker for faster development on linux.
Benjamin Mahler created MESOS-3161:
--
Summary: Document using the gold linker for faster development on
linux.
Key: MESOS-3161
URL: https://issues.apache.org/jira/browse/MESOS-3161
Project: Mesos
Issue Type: Improvement
Components: build, documentation
Reporter: Benjamin Mahler
The [gold linker|https://en.wikipedia.org/wiki/Gold_(linker)] seems to provide
a decent speedup (about ~20%) on a parallel build. From a quick test:
{noformat: title=timings for make check -j24 w/ 24 hyperthreaded cores}
gold:
real7m18.526s
user81m21.213s
sys 5m17.224s
default ld:
real9m7.908s
user85m13.466s
sys 5m52.199s
{noformat}
On CentOS 5 w/ devtoolset-2:
{noformat}
sudo /usr/sbin/alternatives --altdir /opt/rh/devtoolset-2/root/etc/alternatives
--admindir /opt/rh/devtoolset-2/root/var/lib/alternatives --set ld
/opt/rh/devtoolset-2/root/usr/bin/ld.gold
{noformat}
Ideally we could this out on the website, with instructions for each OS.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-2960) Configure DiscoveryInfo and Visibility per port
[ https://issues.apache.org/jira/browse/MESOS-2960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haosdent reassigned MESOS-2960: --- Assignee: haosdent Configure DiscoveryInfo and Visibility per port --- Key: MESOS-2960 URL: https://issues.apache.org/jira/browse/MESOS-2960 Project: Mesos Issue Type: Improvement Components: general Affects Versions: 0.22.1 Reporter: Frank Scholten Assignee: haosdent Labels: mesosphere For Mesos Elasticsearch I like to use DiscoveryInfo to advertise the client port (9200) with Visibility=EXTERNAL so it can be discovered by load balancers while advertising the transport port (9300) as Visibility=FRAMEWORK because it is used by nodes to talk too each other and should not be load balanced. However, I can only set one DiscoveryInfo and one visibility, instead of one per port. I suggest to allow multiple DiscoveryInfo's to be configured with their own visibility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3081) Default configuration of google logging
[ https://issues.apache.org/jira/browse/MESOS-3081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642528#comment-14642528 ] haosdent commented on MESOS-3081: - This ticket seems duplicated with https://issues.apache.org/jira/browse/MESOS-2153 and https://issues.apache.org/jira/browse/MESOS-2153 Default configuration of google logging --- Key: MESOS-3081 URL: https://issues.apache.org/jira/browse/MESOS-3081 Project: Mesos Issue Type: Wish Affects Versions: 0.22.1 Reporter: Rinaldo DiGiorgio Priority: Minor The Google Logging api as configured requires that users look at many files on many systems. When first using mesos log files are important. The idea that having the log output categorized for you is a good idea for production systems but there are many ways and better tools for doing that like logstash and elasticsearch. It would be better if the default configuration was for one logfile with standard conventions rather than many log files. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3057) Mesos web ui sorting by Id results in non-intuitive order.
[ https://issues.apache.org/jira/browse/MESOS-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642550#comment-14642550 ] haosdent commented on MESOS-3057: - I think this ticket is not a problem. The task id maybe defined by your use framework, it could be test_a, test_b, test_c in other frameworks. The better way to fix it is let your use framwork use a fixed bit suffix. For example, like test_1, test_2. Mesos web ui sorting by Id results in non-intuitive order. -- Key: MESOS-3057 URL: https://issues.apache.org/jira/browse/MESOS-3057 Project: Mesos Issue Type: Bug Affects Versions: 0.23.0 Reporter: Cody Roseborough Priority: Trivial Labels: newbie Attachments: web ui sorted by ids.png In the mesos webui sorting task by ID results in non-intuitive order. For example with Id's task_0-task_200 sorted asc you get task_0, task_1, task_10, task_100... task_109, task_11, task_110 etc. It happens if you use just numbers as Id's also. It seems like it should be sorted using natural sort order. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3057) Mesos web ui sorting by Id results in non-intuitive order.
[ https://issues.apache.org/jira/browse/MESOS-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642556#comment-14642556 ] haosdent commented on MESOS-3057: - [~Croseborough] Could you give your framework name to me? Is it open source? Mesos web ui sorting by Id results in non-intuitive order. -- Key: MESOS-3057 URL: https://issues.apache.org/jira/browse/MESOS-3057 Project: Mesos Issue Type: Bug Affects Versions: 0.23.0 Reporter: Cody Roseborough Priority: Trivial Labels: newbie Attachments: web ui sorted by ids.png In the mesos webui sorting task by ID results in non-intuitive order. For example with Id's task_0-task_200 sorted asc you get task_0, task_1, task_10, task_100... task_109, task_11, task_110 etc. It happens if you use just numbers as Id's also. It seems like it should be sorted using natural sort order. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3151) Reservation Test failed
[
https://issues.apache.org/jira/browse/MESOS-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jihun Kang updated MESOS-3151:
--
Environment:
Ubuntu 14.04.2
OpenJDK 1.7.0_79
IBM JDK 1.7.0 SR8
was:
Ubuntu 14.04.2
IBM JDK 1.7.0 SR8
Reservation Test failed
---
Key: MESOS-3151
URL: https://issues.apache.org/jira/browse/MESOS-3151
Project: Mesos
Issue Type: Bug
Environment: Ubuntu 14.04.2
OpenJDK 1.7.0_79
IBM JDK 1.7.0 SR8
Reporter: Jihun Kang
Assignee: Jihun Kang
Here is the details.
{noformat}
[ RUN ]
ReservationTest.CompatibleCheckpointedResourcesWithPersistentVolumes
../../src/tests/reservation_tests.cpp:1055: Failure
Value of: Resources(offer.resources()).contains(unreserved + unreservedDisk)
Actual: false
Expected: true
2015-07-27
17:31:16,280:9247(0x2ae20f41d700):ZOO_ERROR@handle_socket_error_msg@1697:
Socket [127.0.0.1:33182] zk retcode=-4, errno=111(Connection refused): server
refused to accept the client
2015-07-27
17:31:19,617:9247(0x2ae20f41d700):ZOO_ERROR@handle_socket_error_msg@1697:
Socket [127.0.0.1:33182] zk retcode=-4, errno=111(Connection refused): server
refused to accept the client
2015-07-27
17:31:22,951:9247(0x2ae20f41d700):ZOO_ERROR@handle_socket_error_msg@1697:
Socket [127.0.0.1:33182] zk retcode=-4, errno=111(Connection refused): server
refused to accept the client
2015-07-27
17:31:26,288:9247(0x2ae20f41d700):ZOO_ERROR@handle_socket_error_msg@1697:
Socket [127.0.0.1:33182] zk retcode=-4, errno=111(Connection refused): server
refused to accept the client
../../src/tests/reservation_tests.cpp:1076: Failure
Failed to wait 15secs for message1
*** Aborted at 1437985889 (unix time) try date -d @1437985889 if you are
using GNU date ***
PC: @0x0 (unknown)
../../3rdparty/libprocess/include/process/gmock.hpp:365: Failure
Actual function call count doesn't match EXPECT_CALL(filter-mock,
filter(testing::Aconst MessageEvent()))...
Expected args: message matcher (8-byte object C8-39 03-04 E2-2A 00-00,
1-byte object 61, 1-byte object E6)
Expected: to be called once
Actual: never called - unsatisfied and active
../../3rdparty/libprocess/include/process/gmock.hpp:365: Failure
Actual function call count doesn't match EXPECT_CALL(filter-mock,
filter(testing::Aconst MessageEvent()))...
Expected args: message matcher (8-byte object C8-39 03-04 E2-2A 00-00,
1-byte object 61, 1-byte object E6)
Expected: to be called once
Actual: never called - unsatisfied and active
[ FAILED ]
ReservationTest.CompatibleCheckpointedResourcesWithPersistentVolumes (15354
ms)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-527) Command Executors do not have Executor IDs in the master.
[ https://issues.apache.org/jira/browse/MESOS-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14643809#comment-14643809 ] Adam B commented on MESOS-527: -- [~haosd...@gmail.com] Thanks for the attempt, but this ticket is not related to the `mesos-execute` CLI command. Instead, you should look into the `Master::_accept()` and `Master::addTask()` code path. See especially this block where we extract the executorId from an ExecutorInfo (custom executor): https://github.com/apache/mesos/blob/0.23.0/src/master/master.cpp#L2382 For a default/command executor, `has_executor()` will return false, so the master won't know an executorId for this task. After familiarizing yourself with this part of the code (and perhaps `Slave::runTask()`), it should be easier to understand the three options [~bmahler] suggested above. Either the master can set the executorId (to taskId?), we can use an explicit boolean to indicate that these tasks use the default/command executor, or we can workaround the webui issue with other links. Command Executors do not have Executor IDs in the master. - Key: MESOS-527 URL: https://issues.apache.org/jira/browse/MESOS-527 Project: Mesos Issue Type: Bug Reporter: Benjamin Mahler Assignee: haosdent Labels: twitter The webui is broken for command executors because the master does not know the executor ID for the tasks using a command executor. This is because the Task protobuf only has the executor_id field, no other field to indicate the presence of the command executor. It seems the slave also doesn't set the Task.executor_id for command executors, thus relying on it being optionally set in executorTerminated() to determine whether the task used a command executor. This all seems pretty messy, a few things to consider: 1) Should we simply always set the Task.executor_id for these tasks? The master could do so currently, but there would be an implicit contract that the slave and master both use the task id as the executor id. 2) We can add a boolean is_command_executor to Task, so that both the master and slave can set the field, and the slave can use the boolean in executorTerminated() to determine whether the task used a command executor. 3) Alternatively, we can add a /frameworks/FID/tasks/TID url format for the broken links on the master webui, so that we can search for the task in the slave state to locate its executor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-527) Command Executors do not have Executor IDs in the master.
[ https://issues.apache.org/jira/browse/MESOS-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14643813#comment-14643813 ] haosdent commented on MESOS-527: Sorry for misunderstand this ticket #_#. Let me update again. Command Executors do not have Executor IDs in the master. - Key: MESOS-527 URL: https://issues.apache.org/jira/browse/MESOS-527 Project: Mesos Issue Type: Bug Reporter: Benjamin Mahler Assignee: haosdent Labels: twitter The webui is broken for command executors because the master does not know the executor ID for the tasks using a command executor. This is because the Task protobuf only has the executor_id field, no other field to indicate the presence of the command executor. It seems the slave also doesn't set the Task.executor_id for command executors, thus relying on it being optionally set in executorTerminated() to determine whether the task used a command executor. This all seems pretty messy, a few things to consider: 1) Should we simply always set the Task.executor_id for these tasks? The master could do so currently, but there would be an implicit contract that the slave and master both use the task id as the executor id. 2) We can add a boolean is_command_executor to Task, so that both the master and slave can set the field, and the slave can use the boolean in executorTerminated() to determine whether the task used a command executor. 3) Alternatively, we can add a /frameworks/FID/tasks/TID url format for the broken links on the master webui, so that we can search for the task in the slave state to locate its executor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3091) Failed to build scheduler using C++ API: google/protobuf/stubs/common.h: No such file or directory
[ https://issues.apache.org/jira/browse/MESOS-3091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642343#comment-14642343 ] haosdent commented on MESOS-3091: - I think you need install protobuf 2.5.0 manually. Mesos should not install 3rd party headers because it maybe override exists headers. Failed to build scheduler using C++ API: google/protobuf/stubs/common.h: No such file or directory --- Key: MESOS-3091 URL: https://issues.apache.org/jira/browse/MESOS-3091 Project: Mesos Issue Type: Bug Components: c++ api Affects Versions: 0.22.1 Reporter: Mohamed ElTahan When trying to build a scheduler against mesos, the following error is encountered: In file included from /bb/bin/mesos/include/mesos/mesos.hpp:22:0, from /bb/bin/mesos/include/mesos/executor.hpp:26, from mesosbe_BasExecutor.cpp:23: /bb/bin/mesos/include/mesos/mesos.pb.h:9:42: fatal error: google/protobuf/stubs/common.h: No such file or directory #include google/protobuf/stubs/common.h It seems that the problem is mainly mesos's install target only installs mesos's headers and libs but not the headers and libs for the 3rd party packages shipped with mesos -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3150) Comparison Failures on the different precisions of floating-point numbers
[ https://issues.apache.org/jira/browse/MESOS-3150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642354#comment-14642354 ] Jihun Kang commented on MESOS-3150: --- Patches are available on: https://reviews.apache.org/r/36840/ https://reviews.apache.org/r/36841/ Comparison Failures on the different precisions of floating-point numbers - Key: MESOS-3150 URL: https://issues.apache.org/jira/browse/MESOS-3150 Project: Mesos Issue Type: Bug Components: java api, test Affects Versions: 0.22.1 Environment: Ubuntu 14.04.2 IBM JDK 1.7.0 Reporter: Jihun Kang Assignee: Jihun Kang See the details on MESOS-2216. When comparing floating point numbers with different precision, *EXPECT_EQ* function throws errors even expected and actual values are same. It needs to change to the floating-point macros. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3087) Typos in oversubscription doc
[
https://issues.apache.org/jira/browse/MESOS-3087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642319#comment-14642319
]
haosdent commented on MESOS-3087:
-
Patch: https://reviews.apache.org/r/36839/
Typos in oversubscription doc
-
Key: MESOS-3087
URL: https://issues.apache.org/jira/browse/MESOS-3087
Project: Mesos
Issue Type: Documentation
Components: documentation
Affects Versions: 0.23.0
Reporter: Brian Candler
Priority: Trivial
Labels: newbie
* In docs/oversubscription.md: there are three cases where revocable is
written as recovable, including the name of a JSON field.
{noformat}
$ grep -niR recovable .
./docs/oversubscription.md:51:with revocable resources. Further more,
recovable resources cannot be
./docs/oversubscription.md:95:Launching tasks using recovable resources is
done through the existing
./docs/oversubscription.md:96:`launchTasks` API. Revocable resources will
have the `recovable` field set. See
{noformat}
* Also in `docs/oversubscription.md`: the last sentence doesn't make sense
{noformat}
To select custom a resource estimator and QoS controller, please refer to the
[modules documentation](modules.md).
{noformat}
Maybe should say To select a custom... or To install a custom...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-3087) Typos in oversubscription doc
[
https://issues.apache.org/jira/browse/MESOS-3087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
haosdent reassigned MESOS-3087:
---
Assignee: haosdent
Typos in oversubscription doc
-
Key: MESOS-3087
URL: https://issues.apache.org/jira/browse/MESOS-3087
Project: Mesos
Issue Type: Documentation
Components: documentation
Affects Versions: 0.23.0
Reporter: Brian Candler
Assignee: haosdent
Priority: Trivial
Labels: newbie
* In docs/oversubscription.md: there are three cases where revocable is
written as recovable, including the name of a JSON field.
{noformat}
$ grep -niR recovable .
./docs/oversubscription.md:51:with revocable resources. Further more,
recovable resources cannot be
./docs/oversubscription.md:95:Launching tasks using recovable resources is
done through the existing
./docs/oversubscription.md:96:`launchTasks` API. Revocable resources will
have the `recovable` field set. See
{noformat}
* Also in `docs/oversubscription.md`: the last sentence doesn't make sense
{noformat}
To select custom a resource estimator and QoS controller, please refer to the
[modules documentation](modules.md).
{noformat}
Maybe should say To select a custom... or To install a custom...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-3091) Failed to build scheduler using C++ API: google/protobuf/stubs/common.h: No such file or directory
[ https://issues.apache.org/jira/browse/MESOS-3091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642343#comment-14642343 ] haosdent edited comment on MESOS-3091 at 7/27/15 6:39 AM: -- I think you need install protobuf 2.5.0 manually. Mesos should not install 3rd party headers because it may override exists headers. was (Author: haosd...@gmail.com): I think you need install protobuf 2.5.0 manually. Mesos should not install 3rd party headers because it maybe override exists headers. Failed to build scheduler using C++ API: google/protobuf/stubs/common.h: No such file or directory --- Key: MESOS-3091 URL: https://issues.apache.org/jira/browse/MESOS-3091 Project: Mesos Issue Type: Bug Components: c++ api Affects Versions: 0.22.1 Reporter: Mohamed ElTahan When trying to build a scheduler against mesos, the following error is encountered: In file included from /bb/bin/mesos/include/mesos/mesos.hpp:22:0, from /bb/bin/mesos/include/mesos/executor.hpp:26, from mesosbe_BasExecutor.cpp:23: /bb/bin/mesos/include/mesos/mesos.pb.h:9:42: fatal error: google/protobuf/stubs/common.h: No such file or directory #include google/protobuf/stubs/common.h It seems that the problem is mainly mesos's install target only installs mesos's headers and libs but not the headers and libs for the 3rd party packages shipped with mesos -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3126) Building mesos.jar, uses old javadoc plugin in maven.
[ https://issues.apache.org/jira/browse/MESOS-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642377#comment-14642377 ] haosdent commented on MESOS-3126: - [~hbogert] I could build it successfully. Is it because our environment different? I use CenOS 6.5/maven 3.0.5/JDK 1.7.0_75 Building mesos.jar, uses old javadoc plugin in maven. - Key: MESOS-3126 URL: https://issues.apache.org/jira/browse/MESOS-3126 Project: Mesos Issue Type: Bug Components: build Affects Versions: 0.23.0 Environment: Centos 6.5. Manually installed maven, version 3.3.3 Manually installing mesos. Reporter: Hans van den Bogert Priority: Minor When building Mesos, including the mesos.jar. It errors when generating the javadoc: http://pastebin.com/TNRERS4p It seems the javadoc plugin is also trying to parse .class files, though the source directories are correct in the pom file. Further investigation leads to think that the javadoc plugin version is to blame. Setting a fixed version of 2.10.3 for the javadoc plugin, in the pom file, successfully generates the javadoc. In this environment, the default javadoc plugin being downloaded, is 2.8.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2216) The configure phase breaks with the IBM JVM.
[ https://issues.apache.org/jira/browse/MESOS-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642408#comment-14642408 ] Jihun Kang commented on MESOS-2216: --- [~trex58], I fixed up these testing codes in MESOS-3150. IBM JDK returns the floating numbers with different value of exponent part, but google testing function, EXPECT_EQ, does not consider it. I finished up unit tests on x86_64 machines with IBM JDK, but I could not run test on i386 one because I don't have any available 32bit x86 machine. The configure phase breaks with the IBM JVM. -- Key: MESOS-2216 URL: https://issues.apache.org/jira/browse/MESOS-2216 Project: Mesos Issue Type: Bug Affects Versions: 0.20.1, 1.0.0 Environment: Ubuntu / x86_64 Reporter: Tony Reix Assignee: Jihun Kang Attachments: MESOS-2216_1.patch, MESOS-2216_2.patch, config.log, jniport.h, x86_64_traces ./configure does not work with IBM JVM, since it looks for a directory: /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server x86_64 /usr/lib/jvm/ibm-java-ppc64le-71/jre/lib/ppc64le/serverPPC64 LE that does not exist for the IBM JVM. Though this directory does exist for Oracle JVM and Open JDK: /usr/lib/jvm/jdk1.7.0_71/jre/lib/amd64/server Oracle JVM /usr/lib/jvm/java-1.7.0-openjdk-amd64/jre/lib/amd64/server OpenJDK However, the files: libjsig.so libjvm.so (3 versions) do exist for IBM JVM. Anyway, creating the server directory and copying the files (tried with the 3 versions of libjvm.so) does not fix the issue: checking whether or not we can build with JNI... /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined reference to `dlopen' /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined reference to `dlclose' /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined reference to `dlerror' /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined reference to `dlsym' /usr/lib/jvm/ibm-java-x86_64-71/jre/lib/amd64/server/libjvm.so: undefined reference to `dladdr' Something (dlopen, dlclose, dlerror, dlsym, dladdr) is missing in IBM JVM. So, either the configure step relies on a feature that is not in the Java standard but only in the Oracle JVM and OpenJDK, or the IBM JVM lacks part of the Java standard. I'm not an expert about this. So, I'd like Mesos people to experiment with IBM JVM. Maybe there is another solution for this step of the Mesos configure that would work with all 3 JVMs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-3151) Reservation Test failed
Jihun Kang created MESOS-3151:
-
Summary: Reservation Test failed
Key: MESOS-3151
URL: https://issues.apache.org/jira/browse/MESOS-3151
Project: Mesos
Issue Type: Bug
Environment: Ubuntu 14.04.2
IBM JDK 1.7.0 SR8
Reporter: Jihun Kang
Here is the details.
{noformat}
[ RUN ]
ReservationTest.CompatibleCheckpointedResourcesWithPersistentVolumes
../../src/tests/reservation_tests.cpp:1055: Failure
Value of: Resources(offer.resources()).contains(unreserved + unreservedDisk)
Actual: false
Expected: true
2015-07-27
17:31:16,280:9247(0x2ae20f41d700):ZOO_ERROR@handle_socket_error_msg@1697:
Socket [127.0.0.1:33182] zk retcode=-4, errno=111(Connection refused): server
refused to accept the client
2015-07-27
17:31:19,617:9247(0x2ae20f41d700):ZOO_ERROR@handle_socket_error_msg@1697:
Socket [127.0.0.1:33182] zk retcode=-4, errno=111(Connection refused): server
refused to accept the client
2015-07-27
17:31:22,951:9247(0x2ae20f41d700):ZOO_ERROR@handle_socket_error_msg@1697:
Socket [127.0.0.1:33182] zk retcode=-4, errno=111(Connection refused): server
refused to accept the client
2015-07-27
17:31:26,288:9247(0x2ae20f41d700):ZOO_ERROR@handle_socket_error_msg@1697:
Socket [127.0.0.1:33182] zk retcode=-4, errno=111(Connection refused): server
refused to accept the client
../../src/tests/reservation_tests.cpp:1076: Failure
Failed to wait 15secs for message1
*** Aborted at 1437985889 (unix time) try date -d @1437985889 if you are
using GNU date ***
PC: @0x0 (unknown)
../../3rdparty/libprocess/include/process/gmock.hpp:365: Failure
Actual function call count doesn't match EXPECT_CALL(filter-mock,
filter(testing::Aconst MessageEvent()))...
Expected args: message matcher (8-byte object C8-39 03-04 E2-2A 00-00,
1-byte object 61, 1-byte object E6)
Expected: to be called once
Actual: never called - unsatisfied and active
../../3rdparty/libprocess/include/process/gmock.hpp:365: Failure
Actual function call count doesn't match EXPECT_CALL(filter-mock,
filter(testing::Aconst MessageEvent()))...
Expected args: message matcher (8-byte object C8-39 03-04 E2-2A 00-00,
1-byte object 61, 1-byte object E6)
Expected: to be called once
Actual: never called - unsatisfied and active
[ FAILED ]
ReservationTest.CompatibleCheckpointedResourcesWithPersistentVolumes (15354 ms)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-3104) Add an endpoint that exposes component flags.
[ https://issues.apache.org/jira/browse/MESOS-3104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haosdent reassigned MESOS-3104: --- Assignee: haosdent Add an endpoint that exposes component flags. - Key: MESOS-3104 URL: https://issues.apache.org/jira/browse/MESOS-3104 Project: Mesos Issue Type: Task Reporter: David Robinson Assignee: haosdent Priority: Minor Labels: twitter Apparently there's an ongoing effort to break /state.json apart into separate endpoints. As part of this effort it would be great if an endpoint was created that only exposed the flags. Configuration management tools could use the endpoint to determine whether the master/slave is correctly configured. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
