Persisting a List without serialization? JSON maybe?

[stephanos]

Hi,

I'm currently developing an app where most of the action happens in the backend. Now I'm kind of worried about the on-going issues with Java start-up time, you know.

So I'm wondering what I can do now to allow for use of Go/Python just for the frontend later on.

@Serialize is a no-go since it depends on the Java platform. @EmbedMap seems to work fine outside of Java.

So what remains is: how to persist a List (of primitives)?

It seems the solution is a custom serializer? Something that outputs JSON Strings maybe? Where should I start?

Regards

Stephan

[jim.trainor.kanata]

My understanding re java startup time that your good as long you avoid anything that scans your classpath. e.g. jax-rs, guice, jpa.  I avoid those. I use restlet rather than jax-rs, no guice dependency injection (manual DI instead), and objectify rather than jpa (which I would use anyways).  Not anticipating problems.  I don't see any startup problems in the dev environment.  Time will tell - but I did convince myself that java startup issues can be avoided when I first looked into it.

What's the list problem?  Lists in your entity will be stored as property lists on the data store.  If you want to store primitives, e.g. List<String> or List<int> then just add it to you entity.

@Entity
class Thing {
@Id
int id;
List<String> stuffInPropList;
}

"stuffInPropList" will be stored as a property list on the data store.

stephanos wrote:

Hi,

I'm currently developing an app where most of the action happens in
the backend. Now I'm kind of worried about the on-going issues with
Java start-up time, you know.
So I'm wondering what I can do now to allow for use of Go/Python just
for the frontend later on.

@Serialize is a no-go since it depends on the Java platform. @EmbedMap
seems to work fine outside of Java.

So what remains is: /how to persist a List (of primitives)?/

It seems the solution is a custom serializer? Something that outputs
JSON Strings maybe? Where should I start?

Regards
Stephan

--
You received this message because you are subscribed to the Google
Groups "objectify-appengine" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to objectify-appen...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[stephanos]

Well, my app starts in roughly 12 seconds (on F1 instance). I have no dependency injection or other scanning of the classpath, only 15 JARs (~15 MB) and I obviously use Objectify as well. I still find this too slow ... but I yet have to package the class files into a single JAR.

Thanks for clearing things up about the List! Until now I added @Serialize in front of it because I thought it's required :)

Regards

Stephan

an email to objectify-appengine+unsub...@googlegroups.com.

[jim.trainor.kanata]

yeah, 12 seconds seems crazy long.  I'd want to know what it was spending 12 second doing (stating the obvious!).  I've read of such problems, and I've read of the start up delay being resolved by eliminating anything that was doing class path scanning, but I'm still only working in the dev env so I can't offer first hand experience. 

[Nicholas Okunew]

I have a large app which has a 5-6 second startup (which is not great, but hasn't been enough of an issue yet for us to crunch it down further).

We use the thundr DI container, which only does basic reflection to create instances rather than any scanning and it seems fine. If you have long startup times, i'd look to anything thats finding annotations, or any service initialisations which may make remote or slow calls.

--
You received this message because you are subscribed to the Google Groups "objectify-appengine" group.

To unsubscribe from this group and stop receiving emails from it, send an email to objectify-appen...@googlegroups.com.

[stephanos]

That's the thing - besides Objectify's Annotations - I have 0. I use Scala and it has its own dependency injection mechanism which works without and configuration files, annotations or classpath scanning. The downside of course is the 9MB JAR file.

Is there any way to profile the startup?

For example my last loading request took 13.83 s. The servlet initializer I use is able to log "START-UP" after ~7-8s.

So that's about 7s to load and 5s to initialize. I don't know which is worse ;-)

To unsubscribe from this group and stop receiving emails from it, send an email to objectify-appengine+unsub...@googlegroups.com.

[Nicholas Okunew]

Profiling is a little challenging. 

I've used visualvm locally, which is a cheap way of doing it, but you probably couldn't profile startup effectively, and even so its your local dev startup only. You could in theory drop a breakpoint in your code, connect, then continue to see whats within your control (i.e. your application startup, as opposed to resource fetching, container spin-up etc which would be different in the cloud than locally).

I've also done some coarse level manual profiling while running on appengine, that is recording timings yourself - but again, thats within your code rather than anything else. I'm not sure about scala, but if you had some way of adding interceptors/AOP to whatever the Servlet is (even if you have to wrap it), you could time that. Beyond that, I guess its comparisons against the log output for startup.

In conversations with Google previously (a year ago now), they had suggested that Spring was a culprit for slow startups they'd observed in deployed apps - its probably a combination of scanning and jar size, but I wasn't able to get any more info than that really. I wasn't really talking to people who's expertise would match our in the nuances of these technologies either, so I'd take it with a grain of salt.

To unsubscribe from this group and stop receiving emails from it, send an email to objectify-appen...@googlegroups.com.

[Jeff Schnitzer]

The problem with profiling is that anything you think you have learned by profiling on your dev box is not necessarily meaningful in production. It's really not clear exactly what slows down startup in a prod environment - is it classloading? Bytecode generation? Scanning jars? There's something fundamentally different about the prod GAE environment and it takes a lot of very careful instrumentation with a long deploy/test cycle to figure it out. And even then, it's running in-vivo so you can't necessarily compare iteration cycles.

Jeff