Yeah, I get Jetty logs as below:
2015-06-11T04:27:46.34+0200 [RTR] OUT
modules-popeyed-nonascetic.10.244.0.34.xip.io - [11/06/2015:02:27:46
+0000] "GET / HTTP/1.1" 200 1098 "-" "curl/7.29.0" 10.0.2.15:58442
x_forwarded_for:"192.168.2.8, 192.168.50.1, 10.0.2.15"
vcap_request_id:a94d78ae-81a8-4ca4-55f9-9ce8fe9d8f7b
response_time:0.027328613 app_id:9fc4aeb6-15af-407c-baaf-9939b5417f3f
2015-06-11T04:42:23.03+0200 [RTR] OUT
modules-popeyed-nonascetic.10.244.0.34.xip.io - [11/06/2015:02:42:23
+0000] "GET / HTTP/1.1" 200 1098 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64)
AppleWebKit/537.36 (KHTML, like Gecko) Dragon/42.2.2.138
Chrome/42.0.2311.135 Safari/537.36" 10.0.2.15:32833
x_forwarded_for:"192.168.2.8, 192.168.50.1, 10.0.2.15"
vcap_request_id:e24de0c2-d81c-4cd6-76cc-7077bb5ec26c
response_time:0.024409247 app_id:9fc4aeb6-15af-407c-baaf-9939b5417f3f
2015-06-11T04:42:23.29+0200 [RTR] OUT
modules-popeyed-nonascetic.10.244.0.34.xip.io - [11/06/2015:02:42:23
+0000] "GET /favicon.ico HTTP/1.1" 200 1098 "
http://modules-popeyed-nonascetic.10.244.0.34.xip.io/" "Mozilla/5.0
(Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Dragon/
42.2.2.138 Chrome/42.0.2311.135 Safari/537.36" 10.0.2.15:32833
x_forwarded_for:"192.168.2.8, 192.168.50.1, 10.0.2.15"
vcap_request_id:b17c21b4-eba7-4fd5-4fac-4826f89feaae
response_time:0.023473933 app_id:9fc4aeb6-15af-407c-baaf-9939b5417f3f


On Thu, Jun 11, 2015 at 5:48 PM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:

On Thu, Jun 11, 2015 at 11:37 AM, Arbi Akhina <arbi.akhina(a)gmail.com>
wrote:

I removed static assets as well as many classes that were not used,
I left classes related to jetty, javax (managment, ..), apache commons
io, and the package (with all classes) where the main class is located.

Interesting. Do you get log output from the application when it's
working? I'm curious because you weren't seeing this when it was failing.
Trying to understand if the app is not logging properly or if your logs
were being lost somehow.

I didn't try on public cfs like PWS (what is this one?) and BlueMix.

Pivotal Web Services. Similar to Bluemix, it's a public CF that you can
sign up to use. There are others too. The idea here is just to test this
on a larger, more powerful system and see if the problems go away.

Dan

On Thu, Jun 11, 2015 at 4:42 PM, Daniel Mikusa <dmikusa(a)pivotal.io>
wrote:

On Thu, Jun 11, 2015 at 10:31 AM, Arbi Akhina <arbi.akhina(a)gmail.com>
wrote:

Hi, I had to reduce the size of the jar to ~ 51M to get the simple
class that runs jetty to work on bosh-lite!!!

Interesting. Out of curiosity what did you remove to make it smaller?
Static assets? Also have you tried a larger CF install like PWS / BlueMix,
just to see if this is an issue specific to bosh-lite.

Is there any kind of size restriction for executable jars??

The system can put a limit on how big of an application you can
upload. I don't know about bosh-lite specifically, but the default is 1G.
Also, when you exceed that you'll get a message from the cf cli saying your
app is too big. It won't silently fail, which seems to be what happened
here.

Dan

Here is the system information of the warden container on which the
jar is running:
Java version : 1.8.0_45-
Java Spec version : 1.8
JVM version : 25.45-b02
JVM vendor : Oracle Corporation
JVM name : OpenJDK 64-Bit Server VM
Os Name : Linux
Os Architecture : amd64
Os version : 3.13.0-44-generic
Number of processors : 4
Max memory : 3087007744
Total memory : 3087007744
Available memory : 2958157616
Free work disk space : 17898352640
VM Args : [-Djava.io.tmpdir=/home/vcap/tmp,
-XX:OnOutOfMemoryError=/home/vcap/app/.java-buildpack/open_jdk_jre/bin/killjava.sh,
-Xss1M, -Xmx3G, -Xms3G, -XX:MaxMetaspaceSize=419430K,
-XX:MetaspaceSize=419430K]

On Tue, Jun 9, 2015 at 7:01 PM, Arbi Akhina <arbi.akhina(a)gmail.com>
wrote:

no I meant the source is for the company I work for, not my personal
project.

On Tue, Jun 9, 2015 at 6:58 PM, Daniel Mikusa <dmikusa(a)pivotal.io>
wrote:

On Tue, Jun 9, 2015 at 12:43 PM, Arbi Akhina <arbi.akhina(a)gmail.com>
wrote:

I don't own the source, but here is the jar file
http://tempsend.com/6D745B7B07/7033/modules.jar
you can try to run it locally with java -jar modules.jar then
connect to localhost:8080

Hmm, OK. I thought you had a minimal example from you last note.
I'm not really up for running untrusted binary code. If you can put a
minimal code sample together, I'll give it a try.

An here is the manifest.yml i'm using:
---
applications:
- name: modules
memory: 4G
disk_quota: 2G
timeout: 180
instances: 1
host: modules-${random-word}
path: modules.jar
buildpack: https://github.com/cloudfoundry/java-buildpack
command: sleep 2 &&
CALCULATED_MEMORY=$($PWD/.java-buildpack/open_jdk_jre/bin/java-buildpack-memory-calculator-1.1.1_RELEASE
-memorySizes=metaspace:64m..
-memoryWeights=heap:75,metaspace:10,stack:5,native:10
-totMemory=$MEMORY_LIMIT) && $PWD/.java-buildpack/open_jdk_jre/bin/java -cp
$PWD/. -Djava.io.tmpdir=$TMPDIR
-XX:OnOutOfMemoryError=$PWD/.java-buildpack/open_jdk_jre/bin/killjava.sh
$CALCULATED_MEMORY com.heavenize.osmoze.kernel.HelloHandler
# env:
# JAVA_OPTS: "$JAVA_OPTS
-agentlib:jdwp=transport=dt_socket,address=192.168.2.8:8000"

I'm having both files in the same folder modules/ and I push with cf
push

That seems OK. Is this app designed to run on CF? By that, I mean
is it configure to log to STDOUT / STDERR and is it going to listen on the
right port (i.e $PORT)?

Dan

Thanks a lot

On Tue, Jun 9, 2015 at 6:25 PM, Daniel Mikusa <dmikusa(a)pivotal.io>
wrote:

I'd be happy to try the demo and see if it works for me. Can you
post a complete project on github so I can just `git clone` & build?

Dan

On Tue, Jun 9, 2015 at 12:21 PM, Arbi Akhina <
arbi.akhina(a)gmail.com> wrote:

I've tried with a simple app that just launches an embedded jetty
that listen on the vcap port and it worked (I can connect to the app url
from curl and chrome)
then I moved this single file into my modules.jar (the real app)
and configure it as main class, but here it doesn't work.

here is the class in question:
public class HelloHandler extends AbstractHandler
{
public static void main(String[] args)
{
int VCAP_APP_PORT =
Integer.parseInt((System.getenv("VCAP_APP_PORT") != null ?
System.getenv("VCAP_APP_PORT") : "8080"));

Server server = new Server(VCAP_APP_PORT);
server.setHandler(new HelloHandler());

try
{
server.start();
server.join();
}
catch (Exception exception)
{
System.out.println("Failed to start embedded jetty
server.");
exception.printStackTrace();
}
}

final String greeting;
final String body;

public HelloHandler()
{
this("Hello World");
}

public HelloHandler( String greeting )
{
this(greeting, null);
}

public HelloHandler( String greeting, String body )
{
this.greeting = greeting;
this.body = body;
}

public void handle( String target,
Request baseRequest,
HttpServletRequest request,
HttpServletResponse response ) throws
IOException,

ServletException
{
response.setContentType("text/html; charset=utf-8");
response.setStatus(HttpServletResponse.SC_OK);

PrintWriter out = response.getWriter();

out.println("<h1>" + greeting + "</h1>");
out.println("<p>Current directory: " +
getCurrentDirectory() + "</p>");
out.println("<p> Parent directory: " + getParentDirectory()
+ "</p>");
for(File file: getFiles()) {
out.println("<p>" + file.getAbsolutePath() + "</p>");
}

if (body != null)
{
out.println(body);
}

baseRequest.setHandled(true);
}
private List<File> getFiles() {
return Arrays.asList(new File(".").listFiles());
}

private String getCurrentDirectory()
{
String directory = null;
try
{
directory = new File(".").getCanonicalPath();
}
catch (Exception e)
{
e.printStackTrace();
}
return directory;
}

private String getParentDirectory()
{
String directory = null;
try
{
directory = new File("..").getCanonicalPath();
}
catch (Exception e)
{
e.printStackTrace();
}
return directory;
}
}


On Tue, Jun 9, 2015 at 5:34 PM, Daniel Mikusa <dmikusa(a)pivotal.io

wrote:

Double check that your app is configured to log to STDOUT /
STDER. If it's logging to a file, you won't see the messages since the
system only captures STDOUT & STDERR.

Also, you might try a demo app like spring-music, just to make
sure your install is working OK.

https://github.com/cloudfoundry-samples/spring-music

Dan

On Tue, Jun 9, 2015 at 10:40 AM, Arbi Akhina <
arbi.akhina(a)gmail.com> wrote:

Same logs I still can't see what went wrong!

On Tue, Jun 9, 2015 at 3:58 PM, Daniel Mikusa <
dmikusa(a)pivotal.io> wrote:

And so you'd want to set `command` to `sleep 2 &&
CALCULATED_MEMORY=$($PWD/.java-buildpack/open_jdk_jre/
bin/java-buildpack-memory-calculator-1.1.1_RELEASE
-memorySizes=metaspace:64m.. -memoryWeights=heap:75,metaspace:10,stack:5,native:10
-totMemory=$MEMORY_LIMIT) && $PWD/.java-buildpack/open_jdk_jre/bin/java
-cp $PWD/. -Djava.io.tmpdir=$TMPDIR -XX:OnOutOfMemoryError=$PWD/.
java-buildpack/open_jdk_jre/bin/killjava.sh
$CALCULATED_MEMORY -agentlib:jdwp=transport=dt_socket,address=
192.168.2.8:8000 com.heavenize.osmoze.kernel.HelloHandler`.

Dan

On Tue, Jun 9, 2015 at 9:29 AM, Arbi Akhina <
arbi.akhina(a)gmail.com> wrote:

Here is the content of *detected_start_command*:
$ CF_TRACE=true cf app modules | grep "detected_start_command"
"detected_start_command":
"CALCULATED_MEMORY=$($PWD/.java-buildpack/open_jdk_jre/bin/java-buildpack-memory-calculator-1.1.1_RELEASE
-memorySizes=metaspace:64m..
-memoryWeights=heap:75,metaspace:10,stack:5,native:10
-totMemory=$MEMORY_LIMIT) && $PWD/.java-buildpack/open_jdk_jre/bin/java -cp
$PWD/. -Djava.io.tmpdir=$TMPDIR
-XX:OnOutOfMemoryError=$PWD/.java-buildpack/open_jdk_jre/bin/killjava.sh
$CALCULATED_MEMORY -agentlib:jdwp=transport=dt_socket,address=
192.168.2.8:8000 com.heavenize.osmoze.kernel.HelloHandler",

{"guid":"2dabf3c6-1736-4eb4-9bb7-40dc58bce246","name":"modules","routes":[{"guid":"014f77ed-e450-4209-be23-40e4a8257cfc","host":"modules-rhythmic-uvulatomy","domain":{"guid":"a77afa99-76d6-4f3f-9e07-27775597709f","name":"
10.244.0.34.xip.io
"}}],"running_instances":0,"services":[],"available_domains":[{"guid":"a77afa99-76d6-4f3f-9e07-27775597709f","name":"
10.244.0.34.xip.io
"}],"name":"modules","production":false,"space_guid":"381707f7-88d4-4f6e-bd7c-80d7f0699b0f","stack_guid":"3431865a-f165-4e75-9221-4f418e9de889","buildpack":"
https://github.com/cloudfoundry/java-buildpack","detected_buildpack":null,"environment_json":{"JAVA_OPTS":"$JAVA_OPTS
-agentlib:jdwp=transport=dt_socket,address=192.168.2.8:8000"},"memory":4096,"instances":1,"disk_quota":2048,"state":"STARTED","version":"e8f0e18e-7c09-4143-a17c-83a6e32eed84","command":null,"console":false,"debug":null,"staging_task_id":"1249276465c64c1884d401452d2365af","package_state":"STAGED","health_check_type":"port","health_check_timeout":180,"staging_failed_reason":null,"diego":false,"docker_image":null,"package_updated_at":"2015-06-08T07:56:44Z","detected_start_command":"CALCULATED_MEMORY=$($PWD/.java-buildpack/open_jdk_jre/bin/java-buildpack-memory-calculator-1.1.1_RELEASE
-memorySizes=metaspace:64m..
-memoryWeights=heap:75,metaspace:10,stack:5,native:10
-totMemory=$MEMORY_LIMIT) && $PWD/.java-buildpack/open_jdk_jre/bin/java -cp
$PWD/. -Djava.io.tmpdir=$TMPDIR
-XX:OnOutOfMemoryError=$PWD/.java-buildpack/open_jdk_jre/bin/killjava.sh
$CALCULATED_MEMORY -agentlib:jdwp=transport=dt_socket,address=
192.168.2.8:8000 com.heavenize.osmoze.kernel.HelloHandler"}


On Tue, Jun 9, 2015 at 1:35 PM, Daniel Mikusa <
dmikusa(a)pivotal.io> wrote:

On Tue, Jun 9, 2015 at 5:05 AM, Arbi Akhina <
arbi.akhina(a)gmail.com> wrote:

Hi, thanks for the hint, I tried to add to the manifest the
following entry:
command: sleep 2 && java -jar modules.jar

The Java build pack does not put Java on the path, which is
what you're seeing in the error below. I will usually run `CF_TRACE=true
cf app <app-name> | grep "detected_start_command"` which shows the command
the build pack detected and then just copy & paste that into my custom
command.

but it looks like it's not appropriate as I see in the logs:
2015-06-08T05:34:03.71+0200 [App/0] ERR bash: java:
command not found

On Mon, Jun 8, 2015 at 6:32 PM, Daniel Mikusa <
dmikusa(a)pivotal.io> wrote:

On Mon, Jun 8, 2015 at 12:03 PM, Arbi Akhina <
arbi.akhina(a)gmail.com> wrote:

I'm trying to push an executable JAR to a bosh-lite
instance, on the logs I see CF trying many times to restart the app and
eventually fail.

I can't find out why the app crashes as there is no app
logs returned by CF. I tried to remotely debug the app (as described in
[1]) but nothing happens on eclipse. Any hint to solve this issue is
appreciated.

There's a known issue that occurs when an app starts and
fails in rapid succession and results in the log entries being missed. If
you add a couple second pause into the app, it will give the system enough
time to attach the logger and you'll see the output generated by the
crashing app.

You can do this with a custom start command `cf push -c
'sleep 2 && <normal-cmd>'` or with a `.profile.d` script that sleeps for a
couple seconds.

Dan

1. I'm launching the app with:
*cf push -t 180*

2. Here is the manifest.yml content:
---
applications:
- name: modules
memory: 4G
instances: 1
host: modules-${random-word}
path: modules.jar
buildpack:
https://github.com/cloudfoundry/java-buildpack
env:
JAVA_OPTS: "$JAVA_OPTS
-agentlib:jdwp=transport=dt_socket,address=
192.168.2.8:8000"

3. Here is the log:
Connecté, le dumping journaux récents pour application
modules en org heavenize / espace dev comme admin...

2015-06-07T12:05:15.69+0200 [API] OUT Created app
with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:05:16.10+0200 [API] OUT Updated app
with guid 1fbf3378-6512-46de-bae4-02ee30275464
({"route"=>"68e27d8d-4ff6-443b-a3e0-416c40d325d3"})
2015-06-07T12:12:21.55+0200 [DEA] OUT Got staging
request for app with id 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:12:25.40+0200 [API] OUT Updated app
with guid 1fbf3378-6512-46de-bae4-02ee30275464 ({"state"=>"STARTED"})
2015-06-07T12:12:38.08+0200 [STG] OUT ----->
Downloaded app package (163M)
2015-06-07T12:13:40.93+0200 [STG] ERR Cloning
into '/tmp/buildpacks/java-buildpack'...
2015-06-07T12:14:01.67+0200 [STG] OUT -----> Java
Buildpack Version: c862ac8 |
https://github.com/cloudfoundry/java-buildpack#c862ac8
2015-06-07T12:14:13.89+0200 [STG] OUT ----->
Downloading Open Jdk JRE 1.8.0_45 from
https://download.run.pivotal.io/openjdk/lucid/x86_64/openjdk-1.8.0_45.tar.gz
(11.6s)
2015-06-07T12:14:15.34+0200 [STG] OUT
Expanding Open Jdk JRE to .java-buildpack/open_jdk_jre (1.4s)
2015-06-07T12:14:15.89+0200 [STG] OUT ----->
Downloading Open JDK Like Memory Calculator 1.1.1_RELEASE from
https://download.run.pivotal.io/memory-calculator/lucid/x86_64/memory-calculator-1.1.1_RELEASE
(0.5s)
2015-06-07T12:14:15.90+0200 [STG] OUT Memory
Settings: -XX:MaxMetaspaceSize=419430K -XX:MetaspaceSize=419430K -Xss1M
-Xmx3G -Xms3G
2015-06-07T12:15:43.44+0200 [STG] OUT ----->
Uploading droplet (151M)
2015-06-07T12:16:07.51+0200 [DEA] OUT Starting app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:16:29.66+0200 [API] OUT App instance
exited with guid 1fbf3378-6512-46de-bae4-02ee30275464 payload:
{"cc_partition"=>"default",
"droplet"=>"1fbf3378-6512-46de-bae4-02ee30275464",
"version"=>"703f793c-e388-41ac-b1f1-c564b301ca70",
"instance"=>"9d55c5f791324d358bffb4c961a4c7ee", "index"=>0,
"reason"=>"CRASHED", "exit_status"=>-1, "exit_description"=>"failed to
start", "crash_timestamp"=>1433672189}
2015-06-07T12:17:14.18+0200 [DEA] OUT Starting app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:17:31.10+0200 [API] OUT App instance
exited with guid 1fbf3378-6512-46de-bae4-02ee30275464 payload:
{"cc_partition"=>"default",
"droplet"=>"1fbf3378-6512-46de-bae4-02ee30275464",
"version"=>"703f793c-e388-41ac-b1f1-c564b301ca70",
"instance"=>"2ae0c26f33864f40989ee870a1b9e3db", "index"=>0,
"reason"=>"CRASHED", "exit_status"=>-1, "exit_description"=>"failed to
start", "crash_timestamp"=>1433672251}
2015-06-07T12:17:38.48+0200 [DEA] OUT Removing crash
for app with id 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:17:38.48+0200 [DEA] OUT Stopping app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:17:38.48+0200 [DEA] OUT Stopped app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:17:55.31+0200 [DEA] OUT Starting app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:18:11.82+0200 [API] OUT App instance
exited with guid 1fbf3378-6512-46de-bae4-02ee30275464 payload:
{"cc_partition"=>"default",
"droplet"=>"1fbf3378-6512-46de-bae4-02ee30275464",
"version"=>"703f793c-e388-41ac-b1f1-c564b301ca70",
"instance"=>"dc872d38f3324af481c82ba67f0e216c", "index"=>0,
"reason"=>"CRASHED", "exit_status"=>-1, "exit_description"=>"failed to
start", "crash_timestamp"=>1433672291}
2015-06-07T12:18:18.69+0200 [DEA] OUT Removing crash
for app with id 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:18:18.69+0200 [DEA] OUT Stopping app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:18:18.69+0200 [DEA] OUT Stopped app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:18:34.06+0200 [DEA] OUT Starting app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:18:50.98+0200 [API] OUT App instance
exited with guid 1fbf3378-6512-46de-bae4-02ee30275464 payload:
{"cc_partition"=>"default",
"droplet"=>"1fbf3378-6512-46de-bae4-02ee30275464",
"version"=>"703f793c-e388-41ac-b1f1-c564b301ca70",
"instance"=>"623c3af7e3e84801b6fd44eeee9c0a12", "index"=>0,
"reason"=>"CRASHED", "exit_status"=>-1, "exit_description"=>"failed to
start", "crash_timestamp"=>1433672330}
2015-06-07T12:18:58.80+0200 [DEA] OUT Removing crash
for app with id 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:18:58.80+0200 [DEA] OUT Stopping app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:18:58.80+0200 [DEA] OUT Stopped app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:19:34.08+0200 [DEA] OUT Starting app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:19:50.36+0200 [API] OUT App instance
exited with guid 1fbf3378-6512-46de-bae4-02ee30275464 payload:
{"cc_partition"=>"default",
"droplet"=>"1fbf3378-6512-46de-bae4-02ee30275464",
"version"=>"703f793c-e388-41ac-b1f1-c564b301ca70",
"instance"=>"40727eea293146948af197e13443843c", "index"=>0,
"reason"=>"CRASHED", "exit_status"=>-1, "exit_description"=>"failed to
start", "crash_timestamp"=>1433672390}
2015-06-07T12:19:59.01+0200 [DEA] OUT Removing crash
for app with id 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:19:59.01+0200 [DEA] OUT Stopping app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:19:59.01+0200 [DEA] OUT Stopped app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:21:04.12+0200 [DEA] OUT Starting app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:21:20.61+0200 [API] OUT App instance
exited with guid 1fbf3378-6512-46de-bae4-02ee30275464 payload:
{"cc_partition"=>"default",
"droplet"=>"1fbf3378-6512-46de-bae4-02ee30275464",
"version"=>"703f793c-e388-41ac-b1f1-c564b301ca70",
"instance"=>"f7ffff55692a418c847f4f37be574ddf", "index"=>0,
"reason"=>"CRASHED", "exit_status"=>-1, "exit_description"=>"failed to
start", "crash_timestamp"=>1433672480}
2015-06-07T12:21:29.43+0200 [DEA] OUT Removing crash
for app with id 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:21:29.43+0200 [DEA] OUT Stopping app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:21:29.47+0200 [DEA] OUT Stopped app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:23:34.16+0200 [DEA] OUT Starting app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:23:49.97+0200 [API] OUT App instance
exited with guid 1fbf3378-6512-46de-bae4-02ee30275464 payload:
{"cc_partition"=>"default",
"droplet"=>"1fbf3378-6512-46de-bae4-02ee30275464",
"version"=>"703f793c-e388-41ac-b1f1-c564b301ca70",
"instance"=>"4581e97c6b0f4504b8d64a5c69d6787b", "index"=>0,
"reason"=>"CRASHED", "exit_status"=>-1, "exit_description"=>"failed to
start", "crash_timestamp"=>1433672629}
2015-06-07T12:23:50.29+0200 [DEA] OUT Removing crash
for app with id 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:23:50.29+0200 [DEA] OUT Stopping app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:23:50.29+0200 [DEA] OUT Stopped app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:28:14.24+0200 [DEA] OUT Starting app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:28:29.82+0200 [API] OUT App instance
exited with guid 1fbf3378-6512-46de-bae4-02ee30275464 payload:
{"cc_partition"=>"default",
"droplet"=>"1fbf3378-6512-46de-bae4-02ee30275464",
"version"=>"703f793c-e388-41ac-b1f1-c564b301ca70",
"instance"=>"f98749490a6743598f57d3848eb06177", "index"=>0,
"reason"=>"CRASHED", "exit_status"=>-1, "exit_description"=>"failed to
start", "crash_timestamp"=>1433672909}
2015-06-07T12:28:31.73+0200 [DEA] OUT Removing crash
for app with id 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:28:31.73+0200 [DEA] OUT Stopping app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:28:31.73+0200 [DEA] OUT Stopped app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464



[1]
http://docs.cloudfoundry.org/buildpacks/java/java-tips.html#debugging



_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

On Thu, Jun 11, 2015 at 11:37 AM, Arbi Akhina <arbi.akhina(a)gmail.com>
wrote:

I removed static assets as well as many classes that were not used,
I left classes related to jetty, javax (managment, ..), apache commons
io, and the package (with all classes) where the main class is located.

Interesting. Do you get log output from the application when it's
working? I'm curious because you weren't seeing this when it was failing.
Trying to understand if the app is not logging properly or if your logs
were being lost somehow.

I didn't try on public cfs like PWS (what is this one?) and BlueMix.

Pivotal Web Services. Similar to Bluemix, it's a public CF that you can
sign up to use. There are others too. The idea here is just to test this
on a larger, more powerful system and see if the problems go away.

Dan

On Thu, Jun 11, 2015 at 4:42 PM, Daniel Mikusa <dmikusa(a)pivotal.io>
wrote:

On Thu, Jun 11, 2015 at 10:31 AM, Arbi Akhina <arbi.akhina(a)gmail.com>
wrote:

Hi, I had to reduce the size of the jar to ~ 51M to get the simple
class that runs jetty to work on bosh-lite!!!

Interesting. Out of curiosity what did you remove to make it smaller?
Static assets? Also have you tried a larger CF install like PWS / BlueMix,
just to see if this is an issue specific to bosh-lite.

Is there any kind of size restriction for executable jars??

The system can put a limit on how big of an application you can upload.
I don't know about bosh-lite specifically, but the default is 1G. Also,
when you exceed that you'll get a message from the cf cli saying your app
is too big. It won't silently fail, which seems to be what happened here.

Dan

Here is the system information of the warden container on which the jar
is running:
Java version : 1.8.0_45-
Java Spec version : 1.8
JVM version : 25.45-b02
JVM vendor : Oracle Corporation
JVM name : OpenJDK 64-Bit Server VM
Os Name : Linux
Os Architecture : amd64
Os version : 3.13.0-44-generic
Number of processors : 4
Max memory : 3087007744
Total memory : 3087007744
Available memory : 2958157616
Free work disk space : 17898352640
VM Args : [-Djava.io.tmpdir=/home/vcap/tmp,
-XX:OnOutOfMemoryError=/home/vcap/app/.java-buildpack/open_jdk_jre/bin/killjava.sh,
-Xss1M, -Xmx3G, -Xms3G, -XX:MaxMetaspaceSize=419430K,
-XX:MetaspaceSize=419430K]

On Tue, Jun 9, 2015 at 7:01 PM, Arbi Akhina <arbi.akhina(a)gmail.com>
wrote:

no I meant the source is for the company I work for, not my personal
project.

On Tue, Jun 9, 2015 at 6:58 PM, Daniel Mikusa <dmikusa(a)pivotal.io>
wrote:

On Tue, Jun 9, 2015 at 12:43 PM, Arbi Akhina <arbi.akhina(a)gmail.com>
wrote:

I don't own the source, but here is the jar file
http://tempsend.com/6D745B7B07/7033/modules.jar
you can try to run it locally with java -jar modules.jar then
connect to localhost:8080

Hmm, OK. I thought you had a minimal example from you last note.
I'm not really up for running untrusted binary code. If you can put a
minimal code sample together, I'll give it a try.

An here is the manifest.yml i'm using:
---
applications:
- name: modules
memory: 4G
disk_quota: 2G
timeout: 180
instances: 1
host: modules-${random-word}
path: modules.jar
buildpack: https://github.com/cloudfoundry/java-buildpack
command: sleep 2 &&
CALCULATED_MEMORY=$($PWD/.java-buildpack/open_jdk_jre/bin/java-buildpack-memory-calculator-1.1.1_RELEASE
-memorySizes=metaspace:64m..
-memoryWeights=heap:75,metaspace:10,stack:5,native:10
-totMemory=$MEMORY_LIMIT) && $PWD/.java-buildpack/open_jdk_jre/bin/java -cp
$PWD/. -Djava.io.tmpdir=$TMPDIR
-XX:OnOutOfMemoryError=$PWD/.java-buildpack/open_jdk_jre/bin/killjava.sh
$CALCULATED_MEMORY com.heavenize.osmoze.kernel.HelloHandler
# env:
# JAVA_OPTS: "$JAVA_OPTS
-agentlib:jdwp=transport=dt_socket,address=192.168.2.8:8000"

I'm having both files in the same folder modules/ and I push with cf
push

That seems OK. Is this app designed to run on CF? By that, I mean
is it configure to log to STDOUT / STDERR and is it going to listen on the
right port (i.e $PORT)?

Dan

Thanks a lot

On Tue, Jun 9, 2015 at 6:25 PM, Daniel Mikusa <dmikusa(a)pivotal.io>
wrote:

I'd be happy to try the demo and see if it works for me. Can you
post a complete project on github so I can just `git clone` & build?

Dan

On Tue, Jun 9, 2015 at 12:21 PM, Arbi Akhina <arbi.akhina(a)gmail.com

wrote:

I've tried with a simple app that just launches an embedded jetty
that listen on the vcap port and it worked (I can connect to the app url
from curl and chrome)
then I moved this single file into my modules.jar (the real app)
and configure it as main class, but here it doesn't work.

here is the class in question:
public class HelloHandler extends AbstractHandler
{
public static void main(String[] args)
{
int VCAP_APP_PORT =
Integer.parseInt((System.getenv("VCAP_APP_PORT") != null ?
System.getenv("VCAP_APP_PORT") : "8080"));

Server server = new Server(VCAP_APP_PORT);
server.setHandler(new HelloHandler());

try
{
server.start();
server.join();
}
catch (Exception exception)
{
System.out.println("Failed to start embedded jetty server.");
exception.printStackTrace();
}
}

final String greeting;
final String body;

public HelloHandler()
{
this("Hello World");
}

public HelloHandler( String greeting )
{
this(greeting, null);
}

public HelloHandler( String greeting, String body )
{
this.greeting = greeting;
this.body = body;
}

public void handle( String target,
Request baseRequest,
HttpServletRequest request,
HttpServletResponse response ) throws
IOException,

ServletException
{
response.setContentType("text/html; charset=utf-8");
response.setStatus(HttpServletResponse.SC_OK);

PrintWriter out = response.getWriter();

out.println("<h1>" + greeting + "</h1>");
out.println("<p>Current directory: " + getCurrentDirectory()
+ "</p>");
out.println("<p> Parent directory: " + getParentDirectory()
+ "</p>");
for(File file: getFiles()) {
out.println("<p>" + file.getAbsolutePath() + "</p>");
}

if (body != null)
{
out.println(body);
}

baseRequest.setHandled(true);
}
private List<File> getFiles() {
return Arrays.asList(new File(".").listFiles());
}

private String getCurrentDirectory()
{
String directory = null;
try
{
directory = new File(".").getCanonicalPath();
}
catch (Exception e)
{
e.printStackTrace();
}
return directory;
}

private String getParentDirectory()
{
String directory = null;
try
{
directory = new File("..").getCanonicalPath();
}
catch (Exception e)
{
e.printStackTrace();
}
return directory;
}
}


On Tue, Jun 9, 2015 at 5:34 PM, Daniel Mikusa <dmikusa(a)pivotal.io>
wrote:

Double check that your app is configured to log to STDOUT /
STDER. If it's logging to a file, you won't see the messages since the
system only captures STDOUT & STDERR.

Also, you might try a demo app like spring-music, just to make
sure your install is working OK.

https://github.com/cloudfoundry-samples/spring-music

Dan

On Tue, Jun 9, 2015 at 10:40 AM, Arbi Akhina <
arbi.akhina(a)gmail.com> wrote:

Same logs I still can't see what went wrong!

On Tue, Jun 9, 2015 at 3:58 PM, Daniel Mikusa <
dmikusa(a)pivotal.io> wrote:

And so you'd want to set `command` to `sleep 2 &&
CALCULATED_MEMORY=$($PWD/.java-buildpack/open_jdk_jre/
bin/java-buildpack-memory-calculator-1.1.1_RELEASE
-memorySizes=metaspace:64m.. -memoryWeights=heap:75,metaspace:10,stack:5,native:10
-totMemory=$MEMORY_LIMIT) && $PWD/.java-buildpack/open_jdk_jre/bin/java
-cp $PWD/. -Djava.io.tmpdir=$TMPDIR -XX:OnOutOfMemoryError=$PWD/.
java-buildpack/open_jdk_jre/bin/killjava.sh $CALCULATED_MEMORY
-agentlib:jdwp=transport=dt_socket,address=192.168.2.8:8000
com.heavenize.osmoze.kernel.HelloHandler`.

Dan

On Tue, Jun 9, 2015 at 9:29 AM, Arbi Akhina <
arbi.akhina(a)gmail.com> wrote:

Here is the content of *detected_start_command*:
$ CF_TRACE=true cf app modules | grep "detected_start_command"
"detected_start_command":
"CALCULATED_MEMORY=$($PWD/.java-buildpack/open_jdk_jre/bin/java-buildpack-memory-calculator-1.1.1_RELEASE
-memorySizes=metaspace:64m..
-memoryWeights=heap:75,metaspace:10,stack:5,native:10
-totMemory=$MEMORY_LIMIT) && $PWD/.java-buildpack/open_jdk_jre/bin/java -cp
$PWD/. -Djava.io.tmpdir=$TMPDIR
-XX:OnOutOfMemoryError=$PWD/.java-buildpack/open_jdk_jre/bin/killjava.sh
$CALCULATED_MEMORY -agentlib:jdwp=transport=dt_socket,address=
192.168.2.8:8000 com.heavenize.osmoze.kernel.HelloHandler",

{"guid":"2dabf3c6-1736-4eb4-9bb7-40dc58bce246","name":"modules","routes":[{"guid":"014f77ed-e450-4209-be23-40e4a8257cfc","host":"modules-rhythmic-uvulatomy","domain":{"guid":"a77afa99-76d6-4f3f-9e07-27775597709f","name":"
10.244.0.34.xip.io
"}}],"running_instances":0,"services":[],"available_domains":[{"guid":"a77afa99-76d6-4f3f-9e07-27775597709f","name":"
10.244.0.34.xip.io
"}],"name":"modules","production":false,"space_guid":"381707f7-88d4-4f6e-bd7c-80d7f0699b0f","stack_guid":"3431865a-f165-4e75-9221-4f418e9de889","buildpack":"
https://github.com/cloudfoundry/java-buildpack","detected_buildpack":null,"environment_json":{"JAVA_OPTS":"$JAVA_OPTS
-agentlib:jdwp=transport=dt_socket,address=192.168.2.8:8000"},"memory":4096,"instances":1,"disk_quota":2048,"state":"STARTED","version":"e8f0e18e-7c09-4143-a17c-83a6e32eed84","command":null,"console":false,"debug":null,"staging_task_id":"1249276465c64c1884d401452d2365af","package_state":"STAGED","health_check_type":"port","health_check_timeout":180,"staging_failed_reason":null,"diego":false,"docker_image":null,"package_updated_at":"2015-06-08T07:56:44Z","detected_start_command":"CALCULATED_MEMORY=$($PWD/.java-buildpack/open_jdk_jre/bin/java-buildpack-memory-calculator-1.1.1_RELEASE
-memorySizes=metaspace:64m..
-memoryWeights=heap:75,metaspace:10,stack:5,native:10
-totMemory=$MEMORY_LIMIT) && $PWD/.java-buildpack/open_jdk_jre/bin/java -cp
$PWD/. -Djava.io.tmpdir=$TMPDIR
-XX:OnOutOfMemoryError=$PWD/.java-buildpack/open_jdk_jre/bin/killjava.sh
$CALCULATED_MEMORY -agentlib:jdwp=transport=dt_socket,address=
192.168.2.8:8000 com.heavenize.osmoze.kernel.HelloHandler"}


On Tue, Jun 9, 2015 at 1:35 PM, Daniel Mikusa <
dmikusa(a)pivotal.io> wrote:

On Tue, Jun 9, 2015 at 5:05 AM, Arbi Akhina <
arbi.akhina(a)gmail.com> wrote:

Hi, thanks for the hint, I tried to add to the manifest the
following entry:
command: sleep 2 && java -jar modules.jar

The Java build pack does not put Java on the path, which is
what you're seeing in the error below. I will usually run `CF_TRACE=true
cf app <app-name> | grep "detected_start_command"` which shows the command
the build pack detected and then just copy & paste that into my custom
command.

but it looks like it's not appropriate as I see in the logs:
2015-06-08T05:34:03.71+0200 [App/0] ERR bash: java:
command not found

On Mon, Jun 8, 2015 at 6:32 PM, Daniel Mikusa <
dmikusa(a)pivotal.io> wrote:

On Mon, Jun 8, 2015 at 12:03 PM, Arbi Akhina <
arbi.akhina(a)gmail.com> wrote:

I'm trying to push an executable JAR to a bosh-lite
instance, on the logs I see CF trying many times to restart the app and
eventually fail.

I can't find out why the app crashes as there is no app
logs returned by CF. I tried to remotely debug the app (as described in
[1]) but nothing happens on eclipse. Any hint to solve this issue is
appreciated.

There's a known issue that occurs when an app starts and
fails in rapid succession and results in the log entries being missed. If
you add a couple second pause into the app, it will give the system enough
time to attach the logger and you'll see the output generated by the
crashing app.

You can do this with a custom start command `cf push -c
'sleep 2 && <normal-cmd>'` or with a `.profile.d` script that sleeps for a
couple seconds.

Dan

1. I'm launching the app with:
*cf push -t 180*

2. Here is the manifest.yml content:
---
applications:
- name: modules
memory: 4G
instances: 1
host: modules-${random-word}
path: modules.jar
buildpack:
https://github.com/cloudfoundry/java-buildpack
env:
JAVA_OPTS: "$JAVA_OPTS
-agentlib:jdwp=transport=dt_socket,address=
192.168.2.8:8000"

3. Here is the log:
Connecté, le dumping journaux récents pour application
modules en org heavenize / espace dev comme admin...

2015-06-07T12:05:15.69+0200 [API] OUT Created app with
guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:05:16.10+0200 [API] OUT Updated app with
guid 1fbf3378-6512-46de-bae4-02ee30275464
({"route"=>"68e27d8d-4ff6-443b-a3e0-416c40d325d3"})
2015-06-07T12:12:21.55+0200 [DEA] OUT Got staging
request for app with id 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:12:25.40+0200 [API] OUT Updated app with
guid 1fbf3378-6512-46de-bae4-02ee30275464 ({"state"=>"STARTED"})
2015-06-07T12:12:38.08+0200 [STG] OUT ----->
Downloaded app package (163M)
2015-06-07T12:13:40.93+0200 [STG] ERR Cloning into
'/tmp/buildpacks/java-buildpack'...
2015-06-07T12:14:01.67+0200 [STG] OUT -----> Java
Buildpack Version: c862ac8 |
https://github.com/cloudfoundry/java-buildpack#c862ac8
2015-06-07T12:14:13.89+0200 [STG] OUT ----->
Downloading Open Jdk JRE 1.8.0_45 from
https://download.run.pivotal.io/openjdk/lucid/x86_64/openjdk-1.8.0_45.tar.gz
(11.6s)
2015-06-07T12:14:15.34+0200 [STG] OUT Expanding
Open Jdk JRE to .java-buildpack/open_jdk_jre (1.4s)
2015-06-07T12:14:15.89+0200 [STG] OUT ----->
Downloading Open JDK Like Memory Calculator 1.1.1_RELEASE from
https://download.run.pivotal.io/memory-calculator/lucid/x86_64/memory-calculator-1.1.1_RELEASE
(0.5s)
2015-06-07T12:14:15.90+0200 [STG] OUT Memory
Settings: -XX:MaxMetaspaceSize=419430K -XX:MetaspaceSize=419430K -Xss1M
-Xmx3G -Xms3G
2015-06-07T12:15:43.44+0200 [STG] OUT -----> Uploading
droplet (151M)
2015-06-07T12:16:07.51+0200 [DEA] OUT Starting app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:16:29.66+0200 [API] OUT App instance
exited with guid 1fbf3378-6512-46de-bae4-02ee30275464 payload:
{"cc_partition"=>"default",
"droplet"=>"1fbf3378-6512-46de-bae4-02ee30275464",
"version"=>"703f793c-e388-41ac-b1f1-c564b301ca70",
"instance"=>"9d55c5f791324d358bffb4c961a4c7ee", "index"=>0,
"reason"=>"CRASHED", "exit_status"=>-1, "exit_description"=>"failed to
start", "crash_timestamp"=>1433672189}
2015-06-07T12:17:14.18+0200 [DEA] OUT Starting app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:17:31.10+0200 [API] OUT App instance
exited with guid 1fbf3378-6512-46de-bae4-02ee30275464 payload:
{"cc_partition"=>"default",
"droplet"=>"1fbf3378-6512-46de-bae4-02ee30275464",
"version"=>"703f793c-e388-41ac-b1f1-c564b301ca70",
"instance"=>"2ae0c26f33864f40989ee870a1b9e3db", "index"=>0,
"reason"=>"CRASHED", "exit_status"=>-1, "exit_description"=>"failed to
start", "crash_timestamp"=>1433672251}
2015-06-07T12:17:38.48+0200 [DEA] OUT Removing crash
for app with id 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:17:38.48+0200 [DEA] OUT Stopping app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:17:38.48+0200 [DEA] OUT Stopped app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:17:55.31+0200 [DEA] OUT Starting app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:18:11.82+0200 [API] OUT App instance
exited with guid 1fbf3378-6512-46de-bae4-02ee30275464 payload:
{"cc_partition"=>"default",
"droplet"=>"1fbf3378-6512-46de-bae4-02ee30275464",
"version"=>"703f793c-e388-41ac-b1f1-c564b301ca70",
"instance"=>"dc872d38f3324af481c82ba67f0e216c", "index"=>0,
"reason"=>"CRASHED", "exit_status"=>-1, "exit_description"=>"failed to
start", "crash_timestamp"=>1433672291}
2015-06-07T12:18:18.69+0200 [DEA] OUT Removing crash
for app with id 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:18:18.69+0200 [DEA] OUT Stopping app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:18:18.69+0200 [DEA] OUT Stopped app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:18:34.06+0200 [DEA] OUT Starting app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:18:50.98+0200 [API] OUT App instance
exited with guid 1fbf3378-6512-46de-bae4-02ee30275464 payload:
{"cc_partition"=>"default",
"droplet"=>"1fbf3378-6512-46de-bae4-02ee30275464",
"version"=>"703f793c-e388-41ac-b1f1-c564b301ca70",
"instance"=>"623c3af7e3e84801b6fd44eeee9c0a12", "index"=>0,
"reason"=>"CRASHED", "exit_status"=>-1, "exit_description"=>"failed to
start", "crash_timestamp"=>1433672330}
2015-06-07T12:18:58.80+0200 [DEA] OUT Removing crash
for app with id 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:18:58.80+0200 [DEA] OUT Stopping app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:18:58.80+0200 [DEA] OUT Stopped app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:19:34.08+0200 [DEA] OUT Starting app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:19:50.36+0200 [API] OUT App instance
exited with guid 1fbf3378-6512-46de-bae4-02ee30275464 payload:
{"cc_partition"=>"default",
"droplet"=>"1fbf3378-6512-46de-bae4-02ee30275464",
"version"=>"703f793c-e388-41ac-b1f1-c564b301ca70",
"instance"=>"40727eea293146948af197e13443843c", "index"=>0,
"reason"=>"CRASHED", "exit_status"=>-1, "exit_description"=>"failed to
start", "crash_timestamp"=>1433672390}
2015-06-07T12:19:59.01+0200 [DEA] OUT Removing crash
for app with id 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:19:59.01+0200 [DEA] OUT Stopping app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:19:59.01+0200 [DEA] OUT Stopped app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:21:04.12+0200 [DEA] OUT Starting app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:21:20.61+0200 [API] OUT App instance
exited with guid 1fbf3378-6512-46de-bae4-02ee30275464 payload:
{"cc_partition"=>"default",
"droplet"=>"1fbf3378-6512-46de-bae4-02ee30275464",
"version"=>"703f793c-e388-41ac-b1f1-c564b301ca70",
"instance"=>"f7ffff55692a418c847f4f37be574ddf", "index"=>0,
"reason"=>"CRASHED", "exit_status"=>-1, "exit_description"=>"failed to
start", "crash_timestamp"=>1433672480}
2015-06-07T12:21:29.43+0200 [DEA] OUT Removing crash
for app with id 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:21:29.43+0200 [DEA] OUT Stopping app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:21:29.47+0200 [DEA] OUT Stopped app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:23:34.16+0200 [DEA] OUT Starting app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:23:49.97+0200 [API] OUT App instance
exited with guid 1fbf3378-6512-46de-bae4-02ee30275464 payload:
{"cc_partition"=>"default",
"droplet"=>"1fbf3378-6512-46de-bae4-02ee30275464",
"version"=>"703f793c-e388-41ac-b1f1-c564b301ca70",
"instance"=>"4581e97c6b0f4504b8d64a5c69d6787b", "index"=>0,
"reason"=>"CRASHED", "exit_status"=>-1, "exit_description"=>"failed to
start", "crash_timestamp"=>1433672629}
2015-06-07T12:23:50.29+0200 [DEA] OUT Removing crash
for app with id 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:23:50.29+0200 [DEA] OUT Stopping app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:23:50.29+0200 [DEA] OUT Stopped app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:28:14.24+0200 [DEA] OUT Starting app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:28:29.82+0200 [API] OUT App instance
exited with guid 1fbf3378-6512-46de-bae4-02ee30275464 payload:
{"cc_partition"=>"default",
"droplet"=>"1fbf3378-6512-46de-bae4-02ee30275464",
"version"=>"703f793c-e388-41ac-b1f1-c564b301ca70",
"instance"=>"f98749490a6743598f57d3848eb06177", "index"=>0,
"reason"=>"CRASHED", "exit_status"=>-1, "exit_description"=>"failed to
start", "crash_timestamp"=>1433672909}
2015-06-07T12:28:31.73+0200 [DEA] OUT Removing crash
for app with id 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:28:31.73+0200 [DEA] OUT Stopping app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464
2015-06-07T12:28:31.73+0200 [DEA] OUT Stopped app
instance (index 0) with guid 1fbf3378-6512-46de-bae4-02ee30275464



[1]
http://docs.cloudfoundry.org/buildpacks/java/java-tips.html#debugging



_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

Actually, this might explain why some of our customers are so frustrated
trying to read their stack traces in Splunk. :\

So each line of a stack trace could go to a different Doppler. That means
each line of the stack trace goes out to a different syslog drain making it
impossible to consolidate that stack trace into a single logging event when
passed off to a third-party logging system like Splunk. This sucks. To be
fair, Splunk has never been any good at dealing with stack traces.

What are the possibilities of getting some kind of optionally enabled
application instance affinity put into Metron? (I know. I know. I can
submit a PR.)

-Mike

On Thu, Jun 11, 2015 at 3:54 PM, John Tuley <jtuley(a)pivotal.io> wrote:

Oops, wrong link. Should be
https://github.com/cloudfoundry/loggregator/blob/develop/src/metron/main.go#L188-L197
.

Sorry about that!

– John Tuley

On Thu, Jun 11, 2015 at 3:36 PM, John Tuley <jtuley(a)pivotal.io> wrote:

Mike,

Metron chooses a randomly-available Doppler for each message
<https://www.pivotaltracker.com/story/show/96801752>. Availability
prefers same-zone Doppler servers:

- If a Metron instance knows about any same-zone Dopplers, it
chooses one at random for each message.
- If no same-zone Dopplers are present, the random choice is made
from the list of all known servers.


In fact, the behavior you describe is the behavior of DEA Logging Agent
before Metron existed. What we discovered with that approach is that it
balances load very unfairly, as a single high-volume app is stuck on one
server. While the "new" mechanism does not guarantee consistency, it does
enable the Doppler pool to more-evenly share load.

If you're seeing that a single app instance is routed to the same
Doppler server every time, then (without further information) I would guess
that you're either running a single Doppler instance in each availability
zone, or your deck is stacked. :-) If neither of those is true and you're
still observing that Metron routes messages from an app instance to a
single Doppler, I'd love to investigate how that is happening.

– John Tuley

On Thu, Jun 11, 2015 at 2:45 PM, Mike Heath <elcapo(a)gmail.com> wrote:

Metron's documentation [1] says "All Metron traffic is randomly
distributed across available Dopplers." How random is this? Based on
observation, it appears that logs for an individual application instance
are consistently sent to the same Doppler instance. The consistency aspect
is very important for us so that our Syslog forwarder can consolidate stack
traces into a single logging event.

How random is this distribution really for an application instance's
logs?

-Mike

1 - https://github.com/cloudfoundry/loggregator/tree/develop/src/metron

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

One of the really nice features of the V2 Service Broker API is the
ability to broker multiple services from a single process. Each service
provides its unique id in the broker catalog. The Cloud Controller then
includes that unique id with requests to the broker making it easy for the
broker to route the request to the correct service.

The problem I'm currently having is that the API added in version 2.4 for
updating a service instances does not include the service's unique id [1].
It only provides the service instance's id and the new plan id. This makes
it very difficult to route the update request to the correct service
provider within a process brokering multiple services as it would require
querying each service provider to determine if it brokered the provided
instance.

I would like to propose adding a service_id field to the update request,
the same as every other request in the service broker API. I believe that
the main issue with this is that it implies that an instance's service
provider could be changed by the broker. I think proper documentation would
alleviate that issue though.

Thoughts?

-Mike

1 -
http://docs.cloudfoundry.org/services/api.html#updating_service_instance

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

Oops, wrong link. Should be
https://github.com/cloudfoundry/loggregator/blob/develop/src/metron/main.go#L188-L197
.

Sorry about that!

– John Tuley

On Thu, Jun 11, 2015 at 3:36 PM, John Tuley <jtuley(a)pivotal.io> wrote:

Mike,

Metron chooses a randomly-available Doppler for each message
<https://www.pivotaltracker.com/story/show/96801752>. Availability
prefers same-zone Doppler servers:

- If a Metron instance knows about any same-zone Dopplers, it chooses
one at random for each message.
- If no same-zone Dopplers are present, the random choice is made
from the list of all known servers.


In fact, the behavior you describe is the behavior of DEA Logging Agent
before Metron existed. What we discovered with that approach is that it
balances load very unfairly, as a single high-volume app is stuck on one
server. While the "new" mechanism does not guarantee consistency, it does
enable the Doppler pool to more-evenly share load.

If you're seeing that a single app instance is routed to the same Doppler
server every time, then (without further information) I would guess that
you're either running a single Doppler instance in each availability zone,
or your deck is stacked. :-) If neither of those is true and you're still
observing that Metron routes messages from an app instance to a single
Doppler, I'd love to investigate how that is happening.

– John Tuley

On Thu, Jun 11, 2015 at 2:45 PM, Mike Heath <elcapo(a)gmail.com> wrote:

Metron's documentation [1] says "All Metron traffic is randomly
distributed across available Dopplers." How random is this? Based on
observation, it appears that logs for an individual application instance
are consistently sent to the same Doppler instance. The consistency aspect
is very important for us so that our Syslog forwarder can consolidate stack
traces into a single logging event.

How random is this distribution really for an application instance's
logs?

-Mike

1 - https://github.com/cloudfoundry/loggregator/tree/develop/src/metron

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

Mike,

Metron chooses a randomly-available Doppler for each message
<https://www.pivotaltracker.com/story/show/96801752>. Availability
prefers same-zone Doppler servers:

- If a Metron instance knows about any same-zone Dopplers, it chooses
one at random for each message.
- If no same-zone Dopplers are present, the random choice is made from
the list of all known servers.


In fact, the behavior you describe is the behavior of DEA Logging Agent
before Metron existed. What we discovered with that approach is that it
balances load very unfairly, as a single high-volume app is stuck on one
server. While the "new" mechanism does not guarantee consistency, it does
enable the Doppler pool to more-evenly share load.

If you're seeing that a single app instance is routed to the same Doppler
server every time, then (without further information) I would guess that
you're either running a single Doppler instance in each availability zone,
or your deck is stacked. :-) If neither of those is true and you're still
observing that Metron routes messages from an app instance to a single
Doppler, I'd love to investigate how that is happening.

– John Tuley

On Thu, Jun 11, 2015 at 2:45 PM, Mike Heath <elcapo(a)gmail.com> wrote:

Metron's documentation [1] says "All Metron traffic is randomly
distributed across available Dopplers." How random is this? Based on
observation, it appears that logs for an individual application instance
are consistently sent to the same Doppler instance. The consistency aspect
is very important for us so that our Syslog forwarder can consolidate stack
traces into a single logging event.

How random is this distribution really for an application instance's logs?

-Mike

1 - https://github.com/cloudfoundry/loggregator/tree/develop/src/metron

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

Metron's documentation [1] says "All Metron traffic is randomly
distributed across available Dopplers." How random is this? Based on
observation, it appears that logs for an individual application instance
are consistently sent to the same Doppler instance. The consistency aspect
is very important for us so that our Syslog forwarder can consolidate stack
traces into a single logging event.

How random is this distribution really for an application instance's logs?

-Mike

1 - https://github.com/cloudfoundry/loggregator/tree/develop/src/metron

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

Thinking a little more about your question Mohamed. In his presentation
Mike might have made reference to people making adhoc changes to F5. In
our organization today we have a handfull of engineers that have LTM
access. And some of our existing applications that we're moving to Cloud
Foundry do require some specific LTM config or behaviour since they
required that behaviour previously. One of the benfits of NoRouter is it
simplifies the porting of these applications to Cloud Foundry since they
can make the same or similar changes to the LTM that they needed before.
We definitly view these use cases as a hacks though and are using them to
compile a list of official Service Brokers we need to eventually provide
to
formalize this functionality in NoRouter. Other orgs may not have the
requirement and would prefer that nobody touches the LTM. That type of
org
would work well with NoRouter as well.

Hope that helps.

Mike

On Thu, Jun 11, 2015 at 9:50 AM, Mike Youngstrom <youngm(a)gmail.com> wrote:

Thanks for responding Mohamed.

Help me understand what you mean when you refer to opening up the LTM to
developers. NoRouter itself must have access to the LTM to update app
pool
members and such but end users/developers themselves will not actually
have
direct access to the LTM.

Some of the features Mike mentioned in his presentation were more a
comment on what is possible if we enable a feature to do so. When/If
NoRouter were to expose some of that functionality it would most likely
by
done using a Service Broker. For example, if an application wishes to
provide a custom OOS page we wouldn't give the developer direct access
to
the LTM to configure an OOS page, instead, I think we'd provide an OOS
Page
Service Broker. When created and bound to an application it would
prompt
NoRouter to configure the virtual server to use that Custom OOS page for
all of the routers mapped to that application. Keeping the details
sufficiently removed from the developer.

Does that help answer your question?

Mike

On Thu, Jun 11, 2015 at 9:04 AM, Mohamed, Owais <
Owais.Mohamed(a)covisint.com> wrote:

Apologize for restarting this thread after a few weeks.

That?s right Mike. Once the LTM opens up to the developers they might
start putting in too much functionality into the Load Balancer like
filters, interceptors. By using NoRouter the LTM will have to be
opened up
to the developer team.

I know that there has to be discipline and access control. But was
just
putting it out as con in the NoRouter Section.

Hoping that Chip does not have concerns with discussing NoRouter here.
Let me know and I can take this discussion offline.

From: Mike Youngstrom <youngm(a)gmail.com>
Date: Monday, May 18, 2015 at 3:22 PM
To: Chip Childers <cchilders(a)cloudfoundry.org>
Cc: Owais Mohamed <owais.mohamed(a)covisint.com>, "
cf-dev(a)lists.cloudfoundry.org" <cf-dev(a)lists.cloudfoundry.org>
Subject: Re: [cf-dev] TCP Router VS NoRouter

Hi Owais,

What are you referring to when you say you're concerned about the LTM
becoming a Monolith? Too much functionality in one component? Too
much of
the system depending on one component?

Chip,

Hopefully it's ok to discuss NoRouter here even though it isn't an
official CF project. Let us know if it is not.

Mike

On Fri, May 15, 2015 at 10:55 AM, Chip Childers <
cchilders(a)cloudfoundry.org> wrote:

The "norouter", while interesting, isn't the official CF project
approach to HTTP traffic routing. The TCP router is being built to
support
TCP routing as a general solution, with the goal of it becoming an
official
part of the CF release when ready.

-chip

Chip Childers | Technology Chief of Staff | Cloud Foundry Foundation

On Fri, May 15, 2015 at 8:58 AM, Mohamed, Owais <
Owais.Mohamed(a)covisint.com> wrote:

Hi,

I attended sessions on both TCP Router (Cloud Foundry and IOT
protocol support by Atul Kshirsagar) and NoRouter (Norouter: Running
Cloud Foundry without the Gorouter by Mike Heath).

I just wanted to start a discussion on the pros and cons of each
approach.

As personal opinion I think NoRouter is a simpler approach and can
definitely be made to support IOT protocols. The main drawback I see
with
the NoRouter is the danger of the LTM becoming a Monolith.

Any suggestions\ideas?

Regards,
Owais


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

*************************************

wrote:

Ok. Just a question: When you say "the DEA will keep its container carcass
around for an hour", you mean that the DEA does not remove the container
files. However, if Warden grace time is configured at 300 seconds (5
minutes), the container is actually destroyed after that time (although its
files remain). Is this right?

Thank you very much.

2015-06-11 17:27 GMT+02:00 Dieu Cao <dcao(a)pivotal.io>:

Hi Pablo,

Ops Metrics is a PCF product and questions about that should be directed
to Pivotal customer support.

Regarding your second question, about the difference between crashed
indices and crashed indexes.

The NumberOfCrashedInstances metric is usually about 4 times the
NumberOfCrashedIndices metric. First, NumberOfCrashedInstances is the total
number of crashed containers that remain on the DEAs, while
NumberOfCrashedIndices is the number of app-index pairs which have only
crashed instances.

If an app has a droplet that crashes on startup, HM9000 will eventually
settle on restarting an instance at each of its indices every 16
minutes. When the instance crashes, the DEA will keep its container
carcass around for an hour (to allow the space developers to inspect its
files via the files API if they have the instance guid). So on average,
there will be 60/16 = 3.75 crashed instances in the system per crashed
index. That should account for most of the indices and instances that
are crashed in the system.

Hope that helps.

-Dieu
CF Runtime PM



On Thu, Jun 11, 2015 at 4:48 AM, Pablo Alonso Rodriguez <
palonsoro(a)gmail.com> wrote:

Good morning.

Recently, I have been revising metrics emitted by CF components. In
order to understand HM9000 metrics, I have been reading the metrics
documentation (at https://github.com/cloudfoundry/hm9000#metricsserver)

I post this message because I have two questions.

First question:

Not all the metrics retrieved via Ops Metrics are documented there. Is
there any additional documentation? If not, could you please explain my
what do the following metrics mean?

- StartEvacuating, StartCrashed, StartMissing
- StopDuplicate, StopEvacuationComplete, StopExtra

I have some guesses about some of them, but I am not completely sure
about them.

Second question:

I do not fully understand the difference between the concepts of
"instances" and "indices" at metrics like "NumberOfCrashedIndices" and
"NumberOfCrashedInstances".

For example, I have one crashed app in my CF instance, and
"NumberOfCrashedIndices" reports '1' and "NumberOfCrashedInstances" reports
'3'. If I have a look at `cf app myapp`, I see one single crashed instance
(this was expected). If I have a look at hm9000 dump, I see the following
about my crashed app (UUIDs have been replaced by false ones):

Guid: 7ef08c44-102d-11e5-9c0d-0fb30c2610f7 | Version:
8e16b09a-102d-11e5-b6ce-27f9445313f8
Desired: [1] instances, (STARTED, STAGED)
Heartbeats:
[0 CRASHED] a42a7236102d11e5813abfab583ad850 on 1-abc
[0 CRASHED] b35b9f1e102d11e5ad29cfc4c2c4e3ea on 2-ac3
[0 CRASHED] bbd37658102d11e5ba8e2b98d1fd1793 on 4-a67
CrashCounts: [0]:7499
Pending Starts:
[0] priority:1.00 send:2m34.628437793s

So, what does all this mean? I do not understand why do I get 3
heartbeats while
I only was trying to start a single instance.

Thank you in advance




_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

Thanks for responding Mohamed.

Help me understand what you mean when you refer to opening up the LTM to
developers. NoRouter itself must have access to the LTM to update app pool
members and such but end users/developers themselves will not actually have
direct access to the LTM.

Some of the features Mike mentioned in his presentation were more a
comment on what is possible if we enable a feature to do so. When/If
NoRouter were to expose some of that functionality it would most likely by
done using a Service Broker. For example, if an application wishes to
provide a custom OOS page we wouldn't give the developer direct access to
the LTM to configure an OOS page, instead, I think we'd provide an OOS Page
Service Broker. When created and bound to an application it would prompt
NoRouter to configure the virtual server to use that Custom OOS page for
all of the routers mapped to that application. Keeping the details
sufficiently removed from the developer.

Does that help answer your question?

Mike

On Thu, Jun 11, 2015 at 9:04 AM, Mohamed, Owais <
Owais.Mohamed(a)covisint.com> wrote:

Apologize for restarting this thread after a few weeks.

That’s right Mike. Once the LTM opens up to the developers they might
start putting in too much functionality into the Load Balancer like
filters, interceptors. By using NoRouter the LTM will have to be opened up
to the developer team.

I know that there has to be discipline and access control. But was just
putting it out as con in the NoRouter Section.

Hoping that Chip does not have concerns with discussing NoRouter here.
Let me know and I can take this discussion offline.

From: Mike Youngstrom <youngm(a)gmail.com>
Date: Monday, May 18, 2015 at 3:22 PM
To: Chip Childers <cchilders(a)cloudfoundry.org>
Cc: Owais Mohamed <owais.mohamed(a)covisint.com>, "
cf-dev(a)lists.cloudfoundry.org" <cf-dev(a)lists.cloudfoundry.org>
Subject: Re: [cf-dev] TCP Router VS NoRouter

Hi Owais,

What are you referring to when you say you're concerned about the LTM
becoming a Monolith? Too much functionality in one component? Too much of
the system depending on one component?

Chip,

Hopefully it's ok to discuss NoRouter here even though it isn't an
official CF project. Let us know if it is not.

Mike

On Fri, May 15, 2015 at 10:55 AM, Chip Childers <
cchilders(a)cloudfoundry.org> wrote:

The "norouter", while interesting, isn't the official CF project
approach to HTTP traffic routing. The TCP router is being built to support
TCP routing as a general solution, with the goal of it becoming an official
part of the CF release when ready.

-chip

Chip Childers | Technology Chief of Staff | Cloud Foundry Foundation

On Fri, May 15, 2015 at 8:58 AM, Mohamed, Owais <
Owais.Mohamed(a)covisint.com> wrote:

Hi,

I attended sessions on both TCP Router (Cloud Foundry and IOT
protocol support by Atul Kshirsagar) and NoRouter (Norouter: Running
Cloud Foundry without the Gorouter by Mike Heath).

I just wanted to start a discussion on the pros and cons of each
approach.

As personal opinion I think NoRouter is a simpler approach and can
definitely be made to support IOT protocols. The main drawback I see with
the NoRouter is the danger of the LTM becoming a Monolith.

Any suggestions\ideas?

Regards,
Owais


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

We had the same problem due to missing templates in our manifest.

We initially used the example manifest snippet shown at
https://github.com/cloudfoundry/loggregator which mentions only the
doppler template. Looking at
https://github.com/cloudfoundry/loggregator/blob/develop/manifest-templates/cf-lamb.yml we
later determined that we also needed the syslog_drain_binder
and metron_agent templates for a complete loggregator deployment.

-Mike



On Jun 10, 2015, at 9:35 AM, Steve Wall <steve.wall(a)primetimesoftware.com>
wrote:

I was able submit a log entry from the loggregator VM using -

nc -w0 10.xx.xx.xx 5000 <<< "logging from loggregator"

and to test UDP

nc -u -w0 10.xx.xx.xx 5000 <<< "logging from loggregator"


Which leads me to believe the networking is working properly. Any other
thoughts?
Thanks!
Steve

On Wed, Jun 3, 2015 at 6:14 PM, Josh Ghiloni <jghiloni(a)ecsteam.com> wrote:

We’ll check that, thanks!

Josh Ghiloni
Senior Consultant
303.932.2202 o | 303.590.5427 m | 303.565.2794 f
jghiloni(a)ecsteam.com

ECS Team
Technology Solutions Delivered
ECSTeam.com <http://ecsteam.com/>





On Jun 3, 2015, at 15:41, John Tuley <jtuley(a)pivotal.io> wrote:

Steve,

Until recently (cf-release v198), binding a syslog service required
restarting the app. If you're post-v198, it *should* Just Work.

However, one of the things that could be in your way is network
security. In order to forward logs to your drain, your loggregator servers
must be able to access that server. This is the most common cause we see of
systems failing to forward to syslog drains.

Please let us know if you have more questions.

– John Tuley

On Wed, Jun 3, 2015 at 12:37 PM, Steve Wall <
steve.wall(a)primetimesoftware.com> wrote:

Hello,
We are having problems draining log messages to Logstash. The drain is
setup as a user provided service.

cf cups logstash-drain -l syslog://xx.xx.xx.xx:5000

And then bound to the service.

cf bind-service myapp logstash-drain

But no log messages are coming through to Logstash. Or more
specifically, we are using ELK and the messages aren't seen through Kibana.

We were able to log into the DEA and using netcat (nc), messages were
successfully submitted to the ELK stack.

nc -w0 -u xx.xx.xx.xx 5000 <<< "logging from remote"

Any suggestions on how to debug this further?
-Steve


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev



_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev



_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev