gearpump-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kam Kasravi (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (GEARPUMP-39) Error message should indicate the reason of application submission failure
Date Wed, 20 Apr 2016 00:25:25 GMT

    [ https://issues.apache.org/jira/browse/GEARPUMP-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15249022#comment-15249022
] 

Kam Kasravi commented on GEARPUMP-39:
-------------------------------------

Comment from Stanley

Here is an easy step to verify:
1. Start cluster without any worker
2. Submit a wordcount application
3. Check the error log.

According to the log, user is very hard to know, there is no resource available to launch
the application.
{code}
java.io.IOException: Process exit abnormally with code 1 
[INFO] [12/21/2015 14:05:16.183] [ClusterConfig$] loading config file application.conf...
[INFO] [12/21/2015 14:05:16.310] [ClusterConfig$] loading config file application.conf...
[INFO] [12/21/2015 14:05:16.602] [Slf4jLogger] Slf4jLogger started
[INFO] [12/21/2015 14:05:16.685] [Remoting] Starting remoting
[INFO] [12/21/2015 14:05:16.843] [Remoting] Remoting started; listening on addresses :[akka.tcp://client1506396222@127.0.0.1:39588]
[INFO] [12/21/2015 14:05:16.873] [Metrics$] Metrics is enabled...,  true
[INFO] [12/21/2015 14:05:16.875] [ClientContext] Starting system client1506396222
[INFO] [12/21/2015 14:05:16.895] [MasterProxy@masterproxy841884180] Contacts point URL: akka.tcp://master@127.0.0.1:3000/user/master
[INFO] [12/21/2015 14:05:16.898] [MasterProxy@masterproxy841884180] sending identity to ActorSelection[Anchor(akka.tcp://master@127.0.0.1:3000/),
Path(/user/master)]
[INFO] [12/21/2015 14:05:16.898] [MasterProxy@masterproxy841884180] Master Proxy is started...
[INFO] [12/21/2015 14:05:17.040] [MasterProxy@masterproxyclient1506396222] Contacts point
URL: akka.tcp://master@127.0.0.1:3000/user/master
    at io.gearpump.services.MasterService$.submitJar(MasterService.scala:224)
    at io.gearpump.services.MasterService$$anonfun$1$$anonfun$apply$2$$anonfun$apply$3$$anonfun$apply$44$$anonfun$apply$45$$anonfun$apply$46$$anonfun$apply$47$$anonfun$apply$48$$anonfun$apply$1.apply$mcI$sp(MasterService.scala:130)
    at io.gearpump.services.MasterService$$anonfun$1$$anonfun$apply$2$$anonfun$apply$3$$anonfun$apply$44$$anonfun$apply$45$$anonfun$apply$46$$anonfun$apply$47$$anonfun$apply$48$$anonfun$apply$1.apply(MasterService.scala:130)
    at io.gearpump.services.MasterService$$anonfun$1$$anonfun$apply$2$$anonfun$apply$3$$anonfun$apply$44$$anonfun$apply$45$$anonfun$apply$46$$anonfun$apply$47$$anonfun$apply$48$$anonfun$apply$1.apply(MasterService.scala:130)
    at scala.concurrent.impl.Future$PromiseCompletingRunnable.liftedTree1$1(Future.scala:24)
    at scala.concurrent.impl.Future$PromiseCompletingRunnable.run(Future.scala:24)
    at akka.dispatch.TaskInvocation.run(AbstractDispatcher.scala:40)
    at akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(AbstractDispatcher.scala:397)
    at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
    at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)
    at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
    at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)
{code}

> Error message should indicate the reason of application submission failure
> --------------------------------------------------------------------------
>
>                 Key: GEARPUMP-39
>                 URL: https://issues.apache.org/jira/browse/GEARPUMP-39
>             Project: Apache Gearpump
>          Issue Type: Improvement
>          Components: Dashboard
>    Affects Versions: 0.8.0
>            Reporter: Kam Kasravi
>            Priority: Minor
>             Fix For: 0.8.1
>
>
> If a cluster has 1000 free slots, but an application required 1001 slots to start, the
application will be failed to start. We should clearly show the reason in response, rather
than parsing its log to find out the failure reason.
> This suggestion is inspired by investigating #1499



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message