[jira] [Updated] (MESOS-1639) Master OOMs when throttling traffic from LoadGeneratorFramework
[ https://issues.apache.org/jira/browse/MESOS-1639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yan Xu updated MESOS-1639: -- Sprint: Q3 Sprint 1 > Master OOMs when throttling traffic from LoadGeneratorFramework > --- > > Key: MESOS-1639 > URL: https://issues.apache.org/jira/browse/MESOS-1639 > Project: Mesos > Issue Type: Bug >Affects Versions: 0.20.0 >Reporter: Yan Xu >Assignee: Yan Xu > > This happens even with modest burst load (LoadGenerator is not continuously > generating more traffic than master can consume). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MESOS-1639) Master OOMs when throttling traffic from LoadGeneratorFramework
[ https://issues.apache.org/jira/browse/MESOS-1639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14074136#comment-14074136 ] Yan Xu commented on MESOS-1639: --- https://reviews.apache.org/r/23916/ > Master OOMs when throttling traffic from LoadGeneratorFramework > --- > > Key: MESOS-1639 > URL: https://issues.apache.org/jira/browse/MESOS-1639 > Project: Mesos > Issue Type: Bug >Affects Versions: 0.20.0 >Reporter: Yan Xu >Assignee: Yan Xu > > This happens even with modest burst load (LoadGenerator is not continuously > generating more traffic than master can consume). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (MESOS-1639) Master OOMs when throttling traffic from LoadGeneratorFramework
Yan Xu created MESOS-1639: - Summary: Master OOMs when throttling traffic from LoadGeneratorFramework Key: MESOS-1639 URL: https://issues.apache.org/jira/browse/MESOS-1639 Project: Mesos Issue Type: Bug Affects Versions: 0.20.0 Reporter: Yan Xu Assignee: Yan Xu This happens even with modest burst load (LoadGenerator is not continuously generating more traffic than master can consume). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (MESOS-328) HTTP headers should be considered case-insensitive.
[ https://issues.apache.org/jira/browse/MESOS-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Mahler updated MESOS-328: -- Component/s: libprocess > HTTP headers should be considered case-insensitive. > --- > > Key: MESOS-328 > URL: https://issues.apache.org/jira/browse/MESOS-328 > Project: Mesos > Issue Type: Bug > Components: libprocess >Reporter: Benjamin Mahler >Priority: Minor > Labels: twitter > > I found this when writing some tests for the decoder in libprocess. > Message header names should be case-insensitive: > http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2 > Creating this issue to track it, I'm going to add some TODOs for now. > Most clients tend to use Camel-Case for the headers so this is not urgent. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (MESOS-97) Allow a slave to reregister even if it has been removed.
[ https://issues.apache.org/jira/browse/MESOS-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Mahler closed MESOS-97. Resolution: Not a Problem This no longer seems like a problem since we rely heavily on rejecting removed slaves from re-registering, [~benjaminhindman] correct me if I'm mistaken! > Allow a slave to reregister even if it has been removed. > > > Key: MESOS-97 > URL: https://issues.apache.org/jira/browse/MESOS-97 > Project: Mesos > Issue Type: Bug >Reporter: Benjamin Hindman >Assignee: Benjamin Hindman > Labels: twitter > > Currently once a master determines that a slave is "removed" it will not > allow it to reregister ... this could cause an entire cluster to be without > slaves. The current solution has always just been to roll the master. A > better solution is to allow a slave to reregister even if it has been removed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (MESOS-97) Allow a slave to reregister even if it has been removed.
[ https://issues.apache.org/jira/browse/MESOS-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Mahler updated MESOS-97: - Description: Currently once a master determines that a slave is "removed" it will not allow it to reregister ... this could cause an entire cluster to be without slaves. The current solution has always just been to roll the master. A better solution is to allow a slave to reregister even if it has been removed. (was: Currently once a master determines that a slave is "deactivated" it will not allow it to reregister ... this could cause an entire cluster to be without slaves. The current solution has always just been to roll the master. A better solution is to allow a slave to reregister even if it has been deactivated.) Summary: Allow a slave to reregister even if it has been removed. (was: Allow a slave to reregister even if it has been deactivated.) (Updated terminology s/deactivated/removed) > Allow a slave to reregister even if it has been removed. > > > Key: MESOS-97 > URL: https://issues.apache.org/jira/browse/MESOS-97 > Project: Mesos > Issue Type: Bug >Reporter: Benjamin Hindman >Assignee: Benjamin Hindman > Labels: twitter > > Currently once a master determines that a slave is "removed" it will not > allow it to reregister ... this could cause an entire cluster to be without > slaves. The current solution has always just been to roll the master. A > better solution is to allow a slave to reregister even if it has been removed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (MESOS-94) Master and Slave HTTP handlers should have unit tests
[ https://issues.apache.org/jira/browse/MESOS-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Mahler updated MESOS-94: - Labels: http json test (was: http test) > Master and Slave HTTP handlers should have unit tests > - > > Key: MESOS-94 > URL: https://issues.apache.org/jira/browse/MESOS-94 > Project: Mesos > Issue Type: Improvement > Components: json api, master, slave, test >Reporter: Charles Reiss >Assignee: Sumedh Sawant > Labels: http, json, test > > The Master and Slave have HTTP handlers which serve their state (mainly for > the webui to use). There should be unit tests of these. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (MESOS-68) compilation fails on Ubuntu 11.10 without the included zookeeper
[ https://issues.apache.org/jira/browse/MESOS-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Mahler closed MESOS-68. Resolution: Cannot Reproduce Closing since this has become impossibly stale for a build issue. > compilation fails on Ubuntu 11.10 without the included zookeeper > > > Key: MESOS-68 > URL: https://issues.apache.org/jira/browse/MESOS-68 > Project: Mesos > Issue Type: Bug > Environment: Ubuntu Oneric (11.10) >Reporter: Sam Whitlock >Priority: Minor > > When configured with the option --with-included-zookeeper, mesos does not > compile. > --- Relevant Make Output --- > g++ -c -O2 -fno-strict-aliasing -fPIC -g -I. -I. -I../include -I../include > -I../third_party/boost-1.37.0 -I../third_party/protobuf-2.3.0/src > -I../third_party/glog-0.3.1/src -I../third_party/glog-0.3.1/src > -I../third_party/leveldb/include -I../third_party/libprocess/include -MMD -MP > -Ijava/jni -I/usr/lib/jvm/java-7-openjdk-amd64/include > -I/usr/lib/jvm/java-7-openjdk-amd64/include/linux > -I/usr/lib/jvm/java-7-openjdk-amd64/include/linux -o > java/jni/org_apache_mesos_Log.o java/jni/org_apache_mesos_Log.cpp > java/jni/org_apache_mesos_Log.cpp: In function 'void > Java_org_apache_mesos_Log_initialize__ILjava_lang_String_2Ljava_lang_String_2JLjava_util_concurrent_TimeUnit_2Ljava_lang_String_2(JNIEnv*, > jobject, jint, jstring, jstring, jlong, jobject, jstring)': > java/jni/org_apache_mesos_Log.cpp:457:59: error: no matching function for > call to 'mesos::internal::log::Log::Log(int&, std::string&, std::string&, > seconds&, std::string&)' > java/jni/org_apache_mesos_Log.cpp:457:59: note: candidates are: > ./log/log.hpp:153:3: note: mesos::internal::log::Log::Log(int, const string&, > const std::set&) > ./log/log.hpp:153:3: note: candidate expects 3 arguments, 5 provided > ./log/log.hpp:25:7: note: mesos::internal::log::Log::Log(const > mesos::internal::log::Log&) > ./log/log.hpp:25:7: note: candidate expects 1 argument, 5 provided > java/jni/org_apache_mesos_Log.cpp: In function 'void > Java_org_apache_mesos_Log_initialize__ILjava_lang_String_2Ljava_lang_String_2JLjava_util_concurrent_TimeUnit_2Ljava_lang_String_2Ljava_lang_String_2_3B(JNIEnv*, > jobject, jint, jstring, jstring, jlong, jobject, jstring, jstring, > jbyteArray)': > java/jni/org_apache_mesos_Log.cpp:512:5: error: 'zookeeper' has not been > declared > java/jni/org_apache_mesos_Log.cpp:512:31: error: expected ';' before 'auth' > java/jni/org_apache_mesos_Log.cpp:513:5: error: 'auth' was not declared in > this scope > java/jni/org_apache_mesos_Log.cpp:518:56: error: no matching function for > call to 'mesos::internal::log::Log::Log(int&, std::string&, std::string&, > seconds&, std::string&)' > java/jni/org_apache_mesos_Log.cpp:518:56: note: candidates are: > ./log/log.hpp:153:3: note: mesos::internal::log::Log::Log(int, const string&, > const std::set&) > ./log/log.hpp:153:3: note: candidate expects 3 arguments, 5 provided > ./log/log.hpp:25:7: note: mesos::internal::log::Log::Log(const > mesos::internal::log::Log&) > ./log/log.hpp:25:7: note: candidate expects 1 argument, 5 provided > make[1]: *** [java/jni/org_apache_mesos_Log.o] Error 1 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (MESOS-94) Master and Slave HTTP handlers should have unit tests
[ https://issues.apache.org/jira/browse/MESOS-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Mahler updated MESOS-94: - Component/s: json api > Master and Slave HTTP handlers should have unit tests > - > > Key: MESOS-94 > URL: https://issues.apache.org/jira/browse/MESOS-94 > Project: Mesos > Issue Type: Improvement > Components: json api, master, slave, test >Reporter: Charles Reiss >Assignee: Sumedh Sawant > Labels: http, json, test > > The Master and Slave have HTTP handlers which serve their state (mainly for > the webui to use). There should be unit tests of these. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (MESOS-67) Add HTTP File Server component
[
https://issues.apache.org/jira/browse/MESOS-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Mahler closed MESOS-67.
Resolution: Later
Closing since it looks like we'll want to re-evaluate this.
The slave now supports reading files in containers via HTTP through the
{{Files}} abstraction.
Also interesting to note that one could port HDFS to Mesos through the help of
persistent resources: MESOS-1554.
> Add HTTP File Server component
> --
>
> Key: MESOS-67
> URL: https://issues.apache.org/jira/browse/MESOS-67
> Project: Mesos
> Issue Type: Story
> Components: isolation
>Reporter: Haoyuan Li
>Assignee: Haoyuan Li
> Attachments: Mesos HTTP File Server Design Doc-Andys
> Comments-2011-12-12.docx, Mesos HTTP File Server Design Doc.docx
>
>
> Add HTTP file server component.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (MESOS-10) Step-by-step Tutorial of Mesos running 2 versions of Hadoop
[ https://issues.apache.org/jira/browse/MESOS-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Mahler closed MESOS-10. Resolution: Invalid Closing as invalid since we've since re-written the Hadoop 1 port and it is maintained as a separate project: https://github.com/mesos/hadoop > Step-by-step Tutorial of Mesos running 2 versions of Hadoop > --- > > Key: MESOS-10 > URL: https://issues.apache.org/jira/browse/MESOS-10 > Project: Mesos > Issue Type: Documentation > Environment: debian base Linux (Ubuntu), x86 solaris >Reporter: Bill Zhao > Labels: hadoop > Original Estimate: 24h > Remaining Estimate: 24h > > Create something similar to this. > http://www.michael-noll.com/tutorials/running-hadoop-on-ubuntu-linux-multi-node-cluster/#what-we-want-to-do -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (MESOS-9) Implement a simple revocation policy in the SimpleAllocator
[
https://issues.apache.org/jira/browse/MESOS-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Mahler closed MESOS-9.
---
Resolution: Invalid
Resolving as incomplete since there is no longer a {{SimpleAllocator}}.
Revocation work will be taken up in newer ticketing.
> Implement a simple revocation policy in the SimpleAllocator
> ---
>
> Key: MESOS-9
> URL: https://issues.apache.org/jira/browse/MESOS-9
> Project: Mesos
> Issue Type: Story
>Reporter: Matei Zaharia
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (MESOS-1630) Remove framework from completedFrameworks if framework re-registers.
[ https://issues.apache.org/jira/browse/MESOS-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Mathiske reassigned MESOS-1630: - Assignee: Bernd Mathiske > Remove framework from completedFrameworks if framework re-registers. > > > Key: MESOS-1630 > URL: https://issues.apache.org/jira/browse/MESOS-1630 > Project: Mesos > Issue Type: Bug > Components: master >Affects Versions: 0.14.0, 0.14.1, 0.14.2, 0.17.0, 0.16.0, 0.15.0, 0.18.0, > 0.18.1, 0.18.2, 0.19.0, 0.19.1 >Reporter: Benjamin Hindman >Assignee: Bernd Mathiske >Priority: Critical > > If a framework gets removed, for example, because it unregisters with the > master (i.e., due to MESOS-1550), but then the same framework ID is reused > when a framework re-registers (which we currently allow) then we should > remove the framework from Master::completedFrameworks otherwise when a slave > re-registers then in Master::reconcile we'll notice that the slave is > runnings tasks from a completed framework and tell the slave to shutdown that > framework, thus shutting down all of the tasks. > This should be easily fixed by removing the framework from > completedFrameworks when a framework re-registers with the same ID as a > completed framework. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (MESOS-1315) Update master to use a "strict" registry, by default.
[ https://issues.apache.org/jira/browse/MESOS-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Mahler updated MESOS-1315: --- Fix Version/s: (was: 0.20.0) Removing fix version. Will only like to make the default strict when we have a chance to vet it in production and when we have better maintenance / runbook documentation in place. > Update master to use a "strict" registry, by default. > - > > Key: MESOS-1315 > URL: https://issues.apache.org/jira/browse/MESOS-1315 > Project: Mesos > Issue Type: Task >Reporter: Benjamin Mahler > > This is required for 0.20.0. > Upgrading into a "strict" replicated log backed registry can be done smoothly > in two steps: > 0.18.0 -> 0.19.0: this can go to a "non-strict", replicated log backed > registry, which allows the replicated state to be bootstrapped from the > current state of a cluster. The state would not be used to enforce any > decisions. It will be "write-only" in this sense. > 0.19.0 -> 0.20.0: this can move from a "non-strict" replicated log backed > registry, to a "strict" one. This completes the upgrade, at which point > reconciliation would be fully supported. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (MESOS-1219) Master should disallow frameworks that reconnect after failover timeout.
[ https://issues.apache.org/jira/browse/MESOS-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Mahler updated MESOS-1219: --- Fix Version/s: (was: 0.20.0) > Master should disallow frameworks that reconnect after failover timeout. > > > Key: MESOS-1219 > URL: https://issues.apache.org/jira/browse/MESOS-1219 > Project: Mesos > Issue Type: Bug > Components: master, webui >Reporter: Robert Lacroix >Assignee: Vinod Kone > > When a scheduler reconnects after the failover timeout has exceeded, the > framework id is usually reused because the scheduler doesn't know that the > timeout exceeded and it is actually handled as a new framework. > The /framework/:framework_id route of the Web UI doesn't handle those cases > very well because its key is reused. It only shows the terminated one. > Would it make sense to ignore the provided framework id when a scheduler > reconnects to a terminated framework and generate a new id to make sure it's > unique? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MESOS-1635) zk flag fails when specifying a file and the
[ https://issues.apache.org/jira/browse/MESOS-1635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14073923#comment-14073923 ] Ken Sipe commented on MESOS-1635: - @benjamin if you are shepherding... I got this! > zk flag fails when specifying a file and the > - > > Key: MESOS-1635 > URL: https://issues.apache.org/jira/browse/MESOS-1635 > Project: Mesos > Issue Type: Bug > Components: cli >Affects Versions: 0.19.1 > Environment: Linux ubuntu 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 > 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux >Reporter: Ken Sipe > > The zk flag supports referencing a file. It works when registry is > in_memory, however in a "real" environment it fails. > the following starts up just fine. > /usr/local/sbin/mesos-master --zk=file:///etc/mesos/zk --registry=in_memory > however when the follow is executed it fails: > /usr/local/sbin/mesos-master --zk=file:///etc/mesos/zk --quorum=1 > --work_dir=/tmp/mesos > It uses the same working format for the zk flag, but now we are using the > replicated logs. it fails with: > I0723 19:24:34.755506 39856 main.cpp:150] Build: 2014-07-18 18:50:58 by root > I0723 19:24:34.755580 39856 main.cpp:152] Version: 0.19.1 > I0723 19:24:34.755591 39856 main.cpp:155] Git tag: 0.19.1 > I0723 19:24:34.755601 39856 main.cpp:159] Git SHA: > dc0b7bf2a1a7981079b33a16b689892f9cda0d8d > Error parsing ZooKeeper URL: Expecting 'zk://' at the beginning of the URL -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MESOS-947) Slave should properly handle a killTask() that arrives between runTask() and _runTask()
[ https://issues.apache.org/jira/browse/MESOS-947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14073919#comment-14073919 ] Bernd Mathiske commented on MESOS-947: -- These patches are supposed to fix the bug: https://reviews.apache.org/r/23911 https://reviews.apache.org/r/23912 The first adds multihashmap.getKey(). The second is the main patch for MESOS-947. > Slave should properly handle a killTask() that arrives between runTask() and > _runTask() > --- > > Key: MESOS-947 > URL: https://issues.apache.org/jira/browse/MESOS-947 > Project: Mesos > Issue Type: Bug >Reporter: Vinod Kone >Assignee: Bernd Mathiske > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (MESOS-1219) Master should disallow frameworks that reconnect after failover timeout.
[ https://issues.apache.org/jira/browse/MESOS-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Mahler reopened MESOS-1219: This was not committed after all in light of: MESOS-1630 > Master should disallow frameworks that reconnect after failover timeout. > > > Key: MESOS-1219 > URL: https://issues.apache.org/jira/browse/MESOS-1219 > Project: Mesos > Issue Type: Bug > Components: master, webui >Reporter: Robert Lacroix >Assignee: Vinod Kone > Fix For: 0.20.0 > > > When a scheduler reconnects after the failover timeout has exceeded, the > framework id is usually reused because the scheduler doesn't know that the > timeout exceeded and it is actually handled as a new framework. > The /framework/:framework_id route of the Web UI doesn't handle those cases > very well because its key is reused. It only shows the terminated one. > Would it make sense to ignore the provided framework id when a scheduler > reconnects to a terminated framework and generate a new id to make sure it's > unique? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MESOS-1524) Implement Docker support in Mesos
[ https://issues.apache.org/jira/browse/MESOS-1524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14073871#comment-14073871 ] Meghdoot Bhattacharya commented on MESOS-1524: -- Great to see one can run now multiple containerizer at the same time. I know some folks use custom executors to launch docker containers (pre deimos). The point is that in this option if cgroups isolation enabled for MesosContainerizer, the cgroup settings are applied to both the executor and the docker container and I dont think docker has an option to have the cgroup created like a child of the executor cgroup. So, essentially that should lead to 2 independent cgroups getting created. External containerizer avoided it and so will DockerContainerizer. For folks trying to write a custom executor for something like kubernetes, geard etc may fall in this trap if they are expecting to use MesosContainerizer to launch these executors. I know use cases of docker launch modeled as a process in aurora task through thermos that suffers the same issue. Thinking of ways not to partition clusters for docker only workloads. > Implement Docker support in Mesos > - > > Key: MESOS-1524 > URL: https://issues.apache.org/jira/browse/MESOS-1524 > Project: Mesos > Issue Type: Epic >Reporter: Tobi Knaup >Assignee: Benjamin Hindman > > There have been two projects to add Docker support to Mesos, first via an > executor, and more recently via an external containerizer written in Python - > Deimos: https://github.com/mesosphere/deimos > We've got a lot of feedback from folks who use Docker and Mesos, and the main > wish was to make Docker a first class citizen in Mesos instead of a plugin > that needs to be installed separately. Mesos has been using Linux containers > for a long time, first via LXC, then via cgroups, and now also via the > external containerizer. For a long time it wasn't clear what the winning > technology would be, but with Docker becoming the de-facto standard for > handling containers I think Mesos should make it a first class citizen and > part of core. > Let's use this JIRA to track wishes/feedback on the implementation. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (MESOS-1626) Add support for C++11 (+Boost) to stout
[ https://issues.apache.org/jira/browse/MESOS-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14073845#comment-14073845 ] Craig Hansen-Sturm edited comment on MESOS-1626 at 7/24/14 11:43 PM: - Timothy, I have a question for you: I'm hearing that our dependency checker strips out headers for libs containing types which are unreferenced in mainline code. Given this, what is the proper way to introduce (in this case, boost headers) back prior to introducing new dependencies into mainline code ? e.g., adding the declarations, wrapping them in stout, and, only then, using the declarations. I'm assuming a patch for boost is not the right way to do this, but am unsure what the staging process is. Please advise ! thanks. was (Author: craig-mesos): Timothy, I have a question for you: I'm hearing that our dependency checker strips out headers for libs containing types which are unreferenced in the code. Given this, what is the proper way to introduce (in this case, boost headers) back prior to introducing the dependency in mainline code ? I'm assuming a patch is not the right way to do this, but am unsure. Please advise. > Add support for C++11 (+Boost) to stout > > > Key: MESOS-1626 > URL: https://issues.apache.org/jira/browse/MESOS-1626 > Project: Mesos > Issue Type: Improvement > Components: libprocess >Reporter: Craig Hansen-Sturm >Assignee: Craig Hansen-Sturm >Priority: Minor > Attachments: boost-1.53.0.patch > > > Integrate c++11/atomic into libprocess/stout following the pattern introduced > by c++11/memory and c++11/lambda. The primary difference in this case, is > that tr1 did not include support for , this has to come from > boost/atomic which was introduced in v1.53. This task will include a patch > to update boost as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MESOS-1626) Add support for C++11 (+Boost) to stout
[ https://issues.apache.org/jira/browse/MESOS-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14073845#comment-14073845 ] Craig Hansen-Sturm commented on MESOS-1626: --- Timothy, I have a question for you: I'm hearing that our dependency checker strips out headers for libs containing types which are unreferenced in the code. Given this, what is the proper way to introduce (in this case, boost headers) back prior to introducing the dependency in mainline code ? I'm assuming a patch is not the right way to do this, but am unsure. Please advise. > Add support for C++11 (+Boost) to stout > > > Key: MESOS-1626 > URL: https://issues.apache.org/jira/browse/MESOS-1626 > Project: Mesos > Issue Type: Improvement > Components: libprocess >Reporter: Craig Hansen-Sturm >Assignee: Craig Hansen-Sturm >Priority: Minor > Attachments: boost-1.53.0.patch > > > Integrate c++11/atomic into libprocess/stout following the pattern introduced > by c++11/memory and c++11/lambda. The primary difference in this case, is > that tr1 did not include support for , this has to come from > boost/atomic which was introduced in v1.53. This task will include a patch > to update boost as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MESOS-1635) zk flag fails when specifying a file and the
[ https://issues.apache.org/jira/browse/MESOS-1635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14073770#comment-14073770 ] Ken Sipe commented on MESOS-1635: - I've just tested all the mesos master and slave flags. another challenge is that this is the only flag that takes a path to a file which requires the file:// protocol prefix. It would be nice to be consistent with other path flags allowing just the path --zk=/etc/mesos/zk for example. > zk flag fails when specifying a file and the > - > > Key: MESOS-1635 > URL: https://issues.apache.org/jira/browse/MESOS-1635 > Project: Mesos > Issue Type: Bug > Components: cli >Affects Versions: 0.19.1 > Environment: Linux ubuntu 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 > 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux >Reporter: Ken Sipe > > The zk flag supports referencing a file. It works when registry is > in_memory, however in a "real" environment it fails. > the following starts up just fine. > /usr/local/sbin/mesos-master --zk=file:///etc/mesos/zk --registry=in_memory > however when the follow is executed it fails: > /usr/local/sbin/mesos-master --zk=file:///etc/mesos/zk --quorum=1 > --work_dir=/tmp/mesos > It uses the same working format for the zk flag, but now we are using the > replicated logs. it fails with: > I0723 19:24:34.755506 39856 main.cpp:150] Build: 2014-07-18 18:50:58 by root > I0723 19:24:34.755580 39856 main.cpp:152] Version: 0.19.1 > I0723 19:24:34.755591 39856 main.cpp:155] Git tag: 0.19.1 > I0723 19:24:34.755601 39856 main.cpp:159] Git SHA: > dc0b7bf2a1a7981079b33a16b689892f9cda0d8d > Error parsing ZooKeeper URL: Expecting 'zk://' at the beginning of the URL -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (MESOS-1406) Master stats.json using boolean instead of integral value for 'elected'.
[
https://issues.apache.org/jira/browse/MESOS-1406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Mahler updated MESOS-1406:
---
Description:
All stats.json values should be numeric, but it looks like a regression was
introduced here:
{noformat}
commit dee9bd96e88053ab96c84253578ed332d343fe41
Author: Charlie Carson
Date: Thu Feb 20 16:24:09 2014 -0800
Add JSON::Boolean to stout/json.hpp.
If you assign an JSON::Object a bool then it will get coerced into a
JSON::Number w/ value of 0.0 or 1.0. This is because JSON::True and
JSON::False do not have constructors from bool.
The fix is to introduce a common super class, JSON::Boolean, which
both JSON::True and JSON::False inherit from. JSON::Boolean has the
necessary constructor which takes a bool.
However, this leads to ambiguity when assigning a cstring to
a JSON::Value, since JSON::String already takes a const char * and
a const char * is implicitly convertable to a bool.
The solution for that is to rename the variant from JSON::Value
to JSON::inner::Variant and to create a new class JSON::Value
which inherits from JSON::inner::Variant. The new JSON::Value
can have all the conversion constructors in a single place, so
is no ambiguity, and delegate everythign else to the Variant.
Also added a bunch of unit tests.
SEE: https://issues.apache.org/jira/browse/MESOS-939
Review: https://reviews.apache.org/r/17520
{noformat}
This caused all JSON values constructed from booleans to implicitly change from
0/1 to true/false.
was:
All stats.json values should be numeric, but it looks like a regression was
introduced here:
{noformat}
commit f9d1dd819b6cc3843e4d1287ac10276d62cbfed4
Author: Vinod Kone
Date: Tue Nov 19 10:39:27 2013 -0800
Replaced usage of old detector with new Master contender and detector
abstractions.
From: Jiang Yan Xu
Review: https://reviews.apache.org/r/15510
{noformat}
Which appears to have been included since 0.16.0.
Old stats.json:
{code}
{
...
"elected": 0,
...
}
{code}
{code}
{
...
"elected": false,
...
}
{code}
Affects Version/s: (was: 0.18.0)
(was: 0.17.0)
(was: 0.16.0)
Fix Version/s: (was: 0.19.0)
> Master stats.json using boolean instead of integral value for 'elected'.
>
>
> Key: MESOS-1406
> URL: https://issues.apache.org/jira/browse/MESOS-1406
> Project: Mesos
> Issue Type: Bug
>Reporter: Benjamin Mahler
>Assignee: Benjamin Mahler
>
> All stats.json values should be numeric, but it looks like a regression was
> introduced here:
> {noformat}
> commit dee9bd96e88053ab96c84253578ed332d343fe41
> Author: Charlie Carson
> Date: Thu Feb 20 16:24:09 2014 -0800
> Add JSON::Boolean to stout/json.hpp.
> If you assign an JSON::Object a bool then it will get coerced into a
> JSON::Number w/ value of 0.0 or 1.0. This is because JSON::True and
> JSON::False do not have constructors from bool.
> The fix is to introduce a common super class, JSON::Boolean, which
> both JSON::True and JSON::False inherit from. JSON::Boolean has the
> necessary constructor which takes a bool.
> However, this leads to ambiguity when assigning a cstring to
> a JSON::Value, since JSON::String already takes a const char * and
> a const char * is implicitly convertable to a bool.
> The solution for that is to rename the variant from JSON::Value
> to JSON::inner::Variant and to create a new class JSON::Value
> which inherits from JSON::inner::Variant. The new JSON::Value
> can have all the conversion constructors in a single place, so
> is no ambiguity, and delegate everythign else to the Variant.
> Also added a bunch of unit tests.
> SEE: https://issues.apache.org/jira/browse/MESOS-939
> Review: https://reviews.apache.org/r/17520
> {noformat}
> This caused all JSON values constructed from booleans to implicitly change
> from 0/1 to true/false.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (MESOS-1546) Introduce an optional master whitelist for replicated log based registrar.
[ https://issues.apache.org/jira/browse/MESOS-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jie Yu updated MESOS-1546: -- Labels: MesosConHack (was: ) > Introduce an optional master whitelist for replicated log based registrar. > -- > > Key: MESOS-1546 > URL: https://issues.apache.org/jira/browse/MESOS-1546 > Project: Mesos > Issue Type: Improvement > Components: master, replicated log >Reporter: Jie Yu > Labels: MesosConHack > > When using replicated log as the storage back-end for registrar, we currently > rely on ZooKeeper to discover replicas (see ZooKeeperNetwork in > src/log/network.hpp). We simply broadcast Paxos messages to all replicas in > the ZooKeeperNetwork. > There is a security concern using this approach. For example, say initially > there are 3 masters and the quorum size is 2. Now, if a 4th master is > accidentally added and joined the ZooKeeperNetwork, we will then operate at 4 > replicas with quorum size 2. This could lead to inconsistency in the > replicated log (and thus registrar). > The idea here is to introduce a whitelist for masters. We still use > ZooKeeperNetwork to discover replicas. However, when broadcasting Paxos > messages in the replicated log, we check the whitelist and make sure we don't > send Paxos messages to a master that is not in this whitelist. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (MESOS-1546) Introduce an optional master whitelist for replicated log based registrar.
[ https://issues.apache.org/jira/browse/MESOS-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jie Yu updated MESOS-1546: -- Assignee: (was: Jie Yu) > Introduce an optional master whitelist for replicated log based registrar. > -- > > Key: MESOS-1546 > URL: https://issues.apache.org/jira/browse/MESOS-1546 > Project: Mesos > Issue Type: Improvement > Components: master, replicated log >Reporter: Jie Yu > > When using replicated log as the storage back-end for registrar, we currently > rely on ZooKeeper to discover replicas (see ZooKeeperNetwork in > src/log/network.hpp). We simply broadcast Paxos messages to all replicas in > the ZooKeeperNetwork. > There is a security concern using this approach. For example, say initially > there are 3 masters and the quorum size is 2. Now, if a 4th master is > accidentally added and joined the ZooKeeperNetwork, we will then operate at 4 > replicas with quorum size 2. This could lead to inconsistency in the > replicated log (and thus registrar). > The idea here is to introduce a whitelist for masters. We still use > ZooKeeperNetwork to discover replicas. However, when broadcasting Paxos > messages in the replicated log, we check the whitelist and make sure we don't > send Paxos messages to a master that is not in this whitelist. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (MESOS-1638) Create project website section to feature professional support
Dave Lester created MESOS-1638: -- Summary: Create project website section to feature professional support Key: MESOS-1638 URL: https://issues.apache.org/jira/browse/MESOS-1638 Project: Mesos Issue Type: Improvement Components: project website Reporter: Dave Lester Assignee: Dave Lester As I suggested in a dev mailing list thread last September http://markmail.org/thread/o3nlnihmwqtgsm7d, I think it'd be great for the Mesos website/community page to include links to companies that provide Mesos services and support. At the time, we heard from: * Grand Logic * Mesosphere * Big Data Open Source Security LLC Before I made such a change, I wanted to open this ticket to the community to see if there are other companies/individuals that could also be linked to. This info is also important to gather in order to be compliant with Apache's policy of vender neutrality: http://mail-archives.apache.org/mod_mbox/cloudstack-marketing/201303.mbox/%3c5138b...@shanecurcuru.org%3E -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MESOS-1635) zk flag fails when specifying a file and the
[ https://issues.apache.org/jira/browse/MESOS-1635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14073707#comment-14073707 ] Benjamin Mahler commented on MESOS-1635: Looks like there was a TODO left for this: https://github.com/apache/mesos/blob/0.19.1/src/master/main.cpp#L197 I think we should improve URL::parse per the TODO and update these: https://github.com/apache/mesos/blob/0.19.1/src/master/detector.cpp#L107 https://github.com/apache/mesos/blob/0.19.1/src/master/contender.cpp#L73 Should be a simple fix, would be happy to shepherd this if someone wants to pick it up! > zk flag fails when specifying a file and the > - > > Key: MESOS-1635 > URL: https://issues.apache.org/jira/browse/MESOS-1635 > Project: Mesos > Issue Type: Bug > Components: cli >Affects Versions: 0.19.1 > Environment: Linux ubuntu 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 > 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux >Reporter: Ken Sipe > > The zk flag supports referencing a file. It works when registry is > in_memory, however in a "real" environment it fails. > the following starts up just fine. > /usr/local/sbin/mesos-master --zk=file:///etc/mesos/zk --registry=in_memory > however when the follow is executed it fails: > /usr/local/sbin/mesos-master --zk=file:///etc/mesos/zk --quorum=1 > --work_dir=/tmp/mesos > It uses the same working format for the zk flag, but now we are using the > replicated logs. it fails with: > I0723 19:24:34.755506 39856 main.cpp:150] Build: 2014-07-18 18:50:58 by root > I0723 19:24:34.755580 39856 main.cpp:152] Version: 0.19.1 > I0723 19:24:34.755591 39856 main.cpp:155] Git tag: 0.19.1 > I0723 19:24:34.755601 39856 main.cpp:159] Git SHA: > dc0b7bf2a1a7981079b33a16b689892f9cda0d8d > Error parsing ZooKeeper URL: Expecting 'zk://' at the beginning of the URL -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MESOS-73) Add make target for creating Mesos RPM
[
https://issues.apache.org/jira/browse/MESOS-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14073705#comment-14073705
]
Bernardo Gomez Palacio commented on MESOS-73:
-
_Inspired by the latest update by [~davelester]_
For what is worth and as reference to this effort I created the project
[mesos-rpm|https://github.com/berngp/mesos-rpm]. It is basically a build
framework to create Apache Mesos RPMs for any given Git hash or tag. The
default [SPEC
RPM|https://github.com/berngp/mesos-rpm/blob/master/spec/mesos-glabs.spec] file
is targeted for RHEL (Amazon, CentOS, etc) and will help you deploy:
The Masters and Slaves _daemons_ if working with a cluster.
The Local _daemon_ if working with a single node.
The Mesos cli if you want to build or interact with Mesos in a box that won't
host neither the master nor the slave.
The Mesos development headers if you want to build Mesos frameworks.
Note that the spec file has dependencies that can be fulfilled using the EPEL
Repo.
Example of running it:
{code}
export JDK_HOME="/usr/java/jdk1.7.0_51"
export JAVA_HOME="/usr/java/jdk1.7.0_51"
BUILD_NUMBER="${BUILD_NUMBER:-0}" ./mesos-build.sh --qualifier=glabs_h --hashq
--buildnumq --command=mock-flow
{code}
*Note* that the build server needs to be a RHEL Linux box, e.g. CentOS. The
following [chef cookbook|https://github.com/berngp-cookbooks/mesos-buildbox]
can be used as reference on what to install in such _build box_.
> Add make target for creating Mesos RPM
> --
>
> Key: MESOS-73
> URL: https://issues.apache.org/jira/browse/MESOS-73
> Project: Mesos
> Issue Type: Story
>Reporter: Andy Konwinski
> Labels: MesosConHack
>
> This will make it easier for folks to download and try out mesos without
> having to build it, and increase adoption!
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (MESOS-73) Add make target for creating Mesos RPM
[ https://issues.apache.org/jira/browse/MESOS-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Lester updated MESOS-73: - Labels: MesosConHack (was: ) > Add make target for creating Mesos RPM > -- > > Key: MESOS-73 > URL: https://issues.apache.org/jira/browse/MESOS-73 > Project: Mesos > Issue Type: Story >Reporter: Andy Konwinski > Labels: MesosConHack > > This will make it easier for folks to download and try out mesos without > having to build it, and increase adoption! -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (MESOS-1465) Allow '--num_masters' to be specified instead of '--quorum'.
[ https://issues.apache.org/jira/browse/MESOS-1465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Lester updated MESOS-1465: --- Labels: MesosConHack (was: ) > Allow '--num_masters' to be specified instead of '--quorum'. > > > Key: MESOS-1465 > URL: https://issues.apache.org/jira/browse/MESOS-1465 > Project: Mesos > Issue Type: Improvement > Components: master >Affects Versions: 0.20.0 > Environment: master branch HEAD > commit 5172630ae73b7c5f21e1d0e1840a3dc676816582 > Author: Benjamin Mahler > Date: Thu Jun 5 09:49:40 2014 -0700 > Added "implicit" reconciliation. > > Review: https://reviews.apache.org/r/22268 >Reporter: Chengwei Yang > Labels: MesosConHack > > --quorum option introduced for log replication when zookeeper used. Log > replication is a great feature. > However, '--quorum' is not very fit into, considering to below: > # when using with zookeeper, user may confusing with quorum in zookeeper > # user need to learn how quorum works, why it's necessary. > While use '--num_masters', the user is definitely know how many mesos masters > in his/her clusters. It's quite simple and straight-forward. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (MESOS-1637) Slave should support verifying an executor's cryptographic signature
Kevin Sweeney created MESOS-1637: Summary: Slave should support verifying an executor's cryptographic signature Key: MESOS-1637 URL: https://issues.apache.org/jira/browse/MESOS-1637 Project: Mesos Issue Type: Wish Components: security, slave Reporter: Kevin Sweeney Priority: Minor To improve the security and reliability of the launchTask rpc the slave should support verifying the cryptographic signature of executors it downloads as an opt-in feature of ExecutorInfo. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MESOS-947) Slave should properly handle a killTask() that arrives between runTask() and _runTask()
[ https://issues.apache.org/jira/browse/MESOS-947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14073519#comment-14073519 ] Bernd Mathiske commented on MESOS-947: -- [~vi...@twitter.com] Would you like to shepherd this if you have time? I will have a patch ready by tomorrow. > Slave should properly handle a killTask() that arrives between runTask() and > _runTask() > --- > > Key: MESOS-947 > URL: https://issues.apache.org/jira/browse/MESOS-947 > Project: Mesos > Issue Type: Bug >Reporter: Vinod Kone >Assignee: Bernd Mathiske > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (MESOS-1142) Add a 'roles' field to FrameworkInfo.
[ https://issues.apache.org/jira/browse/MESOS-1142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Hindman updated MESOS-1142: Shepherd: Benjamin Hindman > Add a 'roles' field to FrameworkInfo. > - > > Key: MESOS-1142 > URL: https://issues.apache.org/jira/browse/MESOS-1142 > Project: Mesos > Issue Type: Improvement > Components: framework, master, slave >Reporter: Benjamin Hindman > > Currently a framework registers with a single role but in many circumstances > it will make more sense for a framework to be able to be given offers (and > run tasks/executors) from many roles. > We can likely deprecate the single 'role' field in FrameworkInfo and validate > that only one of 'role' or 'roles' is set during registration. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (MESOS-1636) Build failure under jdk1.8.0_11
Amardeep Sarkar created MESOS-1636:
--
Summary: Build failure under jdk1.8.0_11
Key: MESOS-1636
URL: https://issues.apache.org/jira/browse/MESOS-1636
Project: Mesos
Issue Type: Bug
Components: build
Affects Versions: 0.19.1
Environment: CentOS release 6.5 (Final)
Reporter: Amardeep Sarkar
Priority: Trivial
While installing under jdk1.8.0_11 faced the following errors
“[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 03:21 min
[INFO] Finished at: 2014-07-22T21:27:56+05:30
[INFO] Final Memory: 23M/78M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:2.8.1:jar
(build-and-attach-javadocs) on project mesos: MavenReportException: Error while
creating archive:
[ERROR] Exit code: 1 -
/vol1/mesos-0.19.0/build/../src/java/src/org/apache/mesos/Executor.java:41:
error: reference not found
[ERROR] * data to it's executors through the {@link ExecutorInfo#data}
[ERROR] ^
[ERROR]
/vol1/mesos-0.19.0/build/../src/java/src/org/apache/mesos/Executor.java:73:
error: reference not found
[ERROR] * via {@link Scheduler#launchTasks}. Note that this task can be
[ERROR] ^
[ERROR]
/vol1/mesos-0.19.0/build/../src/java/src/org/apache/mesos/Executor.java:81:
warning - Tag @link: can't find launchTasks in org.apache.mesos.Scheduler
[ERROR]
/vol1/mesos-0.19.0/build/../src/java/src/org/apache/mesos/Executor.java:50:
warning - Tag @link: can't find data in org.apache.mesos.Protos.ExecutorInfo
[ERROR] /vol1/mesos-0.19.0/build/../src/java/src/org/apache/mesos/Log.java:251:
warning: no @param for identity
[ERROR] public Position position(byte[] identity) {
[ERROR] ^
[ERROR] /vol1/mesos-0.19.0/build/../src/java/src/org/apache/mesos/Log.java:251:
warning: no @return
[ERROR] public Position position(byte[] identity) {
[ERROR] ^
[ERROR] /vol1/mesos-0.19.0/build/../src/java/src/org/apache/mesos/Log.java:65:
warning: no @return
[ERROR] public byte[] identity() {
[ERROR] ^
[ERROR] /vol1/mesos-0.19.0/build/../src/java/src/org/apache/mesos/Log.java:149:
warning: no @param for from
[ERROR] public native List read(Position from,
[ERROR] ^
[ERROR] /vol1/mesos-0.19.0/build/../src/java/src/org/apache/mesos/Log.java:149:
warning: no @param for to
[ERROR] public native List read(Position from,
[ERROR] ^
[ERROR] /vol1/mesos-0.19.0/build/../src/java/src/org/apache/mesos/Log.java:149:
warning: no @param for timeout
[ERROR] public native List read(Position from,
[ERROR] ^
[ERROR] /vol1/mesos-0.19.0/build/../src/java/src/org/apache/mesos/Log.java:149:
warning: no @param for unit
[ERROR] public native List read(Position from,
[ERROR] ^
[ERROR] /vol1/mesos-0.19.0/build/../src/java/src/org/apache/mesos/Log.java:149:
warning: no @return
[ERROR] public native List read(Position from,
[ERROR] ^
[ERROR] /vol1/mesos-0.19.0/build/../src/java/src/org/apache/mesos/Log.java:149:
warning: no @throws for java.util.concurrent.TimeoutException
[ERROR] public native List read(Position from,
[ERROR] ^
[ERROR] /vol1/mesos-0.19.0/build/../src/java/src/org/apache/mesos/Log.java:149:
warning: no @throws for org.apache.mesos.Log.OperationFailedException
[ERROR] public native List read(Position from,
[ERROR] ^
[ERROR] /vol1/mesos-0.19.0/build/../src/java/src/org/apache/mesos/Log.java:159:
warning: no @return
[ERROR] public native Position beginning();
[ERROR] ^
[ERROR] /vol1/mesos-0.19.0/build/../src/java/src/org/apache/mesos/Log.java:165:
warning: no @return
[ERROR] public native Position ending();
[ERROR] ^
[ERROR] /vol1/mesos-0.19.0/build/../src/java/src/org/apache/mesos/Log.java:191:
warning: no @param for data
[ERROR] public native Position append(byte[] data, long timeout, TimeUnit unit)
[ERROR] ^
[ERROR] /vol1/mesos-0.19.0/build/../src/java/src/org/apache/mesos/Log.java:191:
warning: no @param for timeout
[ERROR] public native Position append(byte[] data, long timeout, TimeUnit unit)
[ERROR] ^
[ERROR] /vol1/mesos-0.19.0/build/../src/java/src/org/apache/mesos/Log.java:191:
warning: no @param for unit
[ERROR] public native Position append(byte[] data, long timeout, TimeUnit unit)
[ERROR] ^
[ERROR] /vol1/mesos-0.19.0/build/../src/java/src/org/apache/mesos/Log.java:191:
warning: no @return
[ERROR] public native Position append(byte[] data, long timeout, TimeUnit unit)
[ERROR] ^
[ERROR] /vol1/mesos-0.19.0/build/../src/java/src/org/apache/mesos/Log.java:191:
warning: no @throws for java.util.concurrent.TimeoutException
[ERROR] public native Position append(byte[] data, long timeout, TimeUnit unit)
[ERROR] ^
[ERROR] /vol1/mesos-0.19.0/build/../src/java/src/org/apache/mesos/Log.java:191:
warning: no @throws for org.apache.mesos.Log.WriterFailedExcepti
[jira] [Closed] (MESOS-1288) Use maven to compile and package Mesos' Java files.
[ https://issues.apache.org/jira/browse/MESOS-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernardo Gomez Palacio closed MESOS-1288. - Resolution: Won't Fix Fix Version/s: 0.18.0 0.19.0 > Use maven to compile and package Mesos' Java files. > --- > > Key: MESOS-1288 > URL: https://issues.apache.org/jira/browse/MESOS-1288 > Project: Mesos > Issue Type: Sub-task > Components: build, java api >Affects Versions: 0.17.0 >Reporter: Bernardo Gomez Palacio >Assignee: Bernardo Gomez Palacio > Fix For: 0.19.0, 0.18.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (MESOS-1289) Fix Javadocs so that the Maven task javadoc:javadoc doesn't fail while building the jars.
[ https://issues.apache.org/jira/browse/MESOS-1289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernardo Gomez Palacio closed MESOS-1289. - Resolution: Won't Fix Fix Version/s: 0.18.2 0.19.0 > Fix Javadocs so that the Maven task javadoc:javadoc doesn't fail while > building the jars. > - > > Key: MESOS-1289 > URL: https://issues.apache.org/jira/browse/MESOS-1289 > Project: Mesos > Issue Type: Sub-task > Components: build, java api >Affects Versions: 0.17.0 >Reporter: Bernardo Gomez Palacio >Assignee: Bernardo Gomez Palacio > Fix For: 0.19.0, 0.18.2 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
