search

codyopel / collide

Automatically exported from code.google.com/p/collide
Apache License 2.0
0 stars 0 forks source link

collide script invoking vertx should accept user-supplied jvm arguments #16

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Deploy collide to aws
2. Run for a while
3. Wait

java.lang.OutOfMemoryError: Java heap space
    at java.lang.AbstractStringBuilder.<init>(AbstractStringBuilder.java:64)
    at java.lang.StringBuilder.<init>(StringBuilder.java:97)
    at org.codehaus.jackson.util.TextBuffer.contentsAsString(TextBuffer.java:352)
    at org.codehaus.jackson.io.SegmentedStringWriter.getAndClear(SegmentedStringWriter.java:100)
    at org.codehaus.jackson.map.ObjectMapper.writeValueAsString(ObjectMapper.java:2098)
    at org.vertx.java.core.sockjs.impl.JsonCodec.encode(JsonCodec.java:107)
    at org.vertx.java.core.sockjs.impl.Session.writePendingMessages(Session.java:188)
    at org.vertx.java.core.sockjs.impl.Session.write(Session.java:91)
    at org.vertx.java.core.sockjs.impl.Session.writeBuffer(Session.java:114)
    at org.vertx.java.core.sockjs.impl.EventBusBridge.deliverMessage(EventBusBridge.java:224)
    at org.vertx.java.core.sockjs.impl.EventBusBridge.access$500(EventBusBridge.java:49)
    at org.vertx.java.core.sockjs.impl.EventBusBridge$5.handle(EventBusBridge.java:265)
    at org.vertx.java.core.sockjs.impl.EventBusBridge$5.handle(EventBusBridge.java:259)
    at org.vertx.java.core.eventbus.impl.DefaultEventBus$7.run(DefaultEventBus.java:601)
    at org.vertx.java.core.impl.Context$2.run(Context.java:119)
    at org.jboss.netty.channel.socket.nio.AbstractNioWorker.processEventQueue(AbstractNioWorker.java:360)
    at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:244)
    at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:38)
    at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:102)
    at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
    at java.lang.Thread.run(Thread.java:722)

The supplied stacktrace changes every time, as one would expect from an OOM.

Workaround: Put -Xmx1024m -XX:MaxPermSize=1280m in the appropriate files, or a 
flag to pass settings through to the invocation of java in vert.x

I tried adding them in the bin/deploy/collide script, as well as in 
/bin/deploy/lib/vert.x, but both tries just made the command line complain 
about unexpected tokens.

Original issue reported on code.google.com by Ja...@wetheinter.net on 5 Jul 2012 at 3:44

GoogleCodeExporter commented 9 years ago 
Looks like the vertx script has no mechanism for passing through arbitrary JVM 
flags, so there's no real way to get them from the collide script into there.

We've talked about merging the vertx script contents into collide itself for 
finer grained control.  Suggestions?

Filing a new issue to actually look at consumed memory.

Original comment by dragonsinth on 5 Jul 2012 at 4:59

GoogleCodeExporter commented 9 years ago 
Well... we actually know why its running out of memory :). We didn't have time 
to implement garbage collection of file edit sessions.

I also suspect a leak in vertx itself (or our usage of the event bus).

I would actually posit that the proper fix should be to plug the memory leaks. 
It has enough memory by default.

Original comment by jaime...@gmail.com on 5 Jul 2012 at 5:14

GoogleCodeExporter commented 9 years ago 
Jaime: I filed a new issue #17 for actually improving memory use.

Are you saying we shouldn't bump the memory at all?

Original comment by dragonsinth on 5 Jul 2012 at 5:16

GoogleCodeExporter commented 9 years ago 
Right. Unless we see that normal usage puts us close to the brink. However I 
suspect that when we profile the server we will see that the leak is to blame, 
and the baseline heap space usage is probably pretty small.

Original comment by jaime...@gmail.com on 5 Jul 2012 at 5:23

GoogleCodeExporter commented 9 years ago 
Plugging memory leaks is always the preferred solution. 

It would still be wise to pass along arbitrary jvm arguments for a host of 
other reasons {memory, debugging, GC options, etc}.  Maybe something as simple 
as a jvm.config file so we don't have to parse and pass the arguments in the 
scripts?

Original comment by Ja...@wetheinter.net on 6 Jul 2012 at 9:30

GoogleCodeExporter commented 9 years ago

Original comment by Ja...@wetheinter.net on 6 Jul 2012 at 9:50

GoogleCodeExporter commented 9 years ago 
Is jvm.config a standard Java thing?  I've never heard of it, but I went
searching and found mostly ColdFusion stuff.

Original comment by dragonsinth on 7 Jul 2012 at 4:38

GoogleCodeExporter commented 9 years ago 
Oh, I just made up the name jvm.config, sorry.  =}  

I was thinking just a text file with jvm flags on each line would make sense.  
Just a simple way to pass configuration into the vertx java command, without 
having to actually modify the executable.

Like eclipse.ini, really.  collide.ini, maybe?

Original comment by Ja...@wetheinter.net on 7 Jul 2012 at 6:16