[Java] Glassfish RESTful 1 maal laten initialiseren

[Red devil]

Beste Tweakers,

Voorheen via SOAP data naar clients beschikbaar gesteld. Maar nu krijgen mijn geliefde collegas de koppeling mbv Perl niet aan de praat
Zou het nu via REST willen proberen. Middels REST wil ik clients toegang geven tot een text index die ik gemaakt heb met Lucene. Omdat het openen van deze index nogal wat tijd neemt zou het handig zijn als deze éénmalig ingeladen wordt en daarna beschikbaar blijft. Als applicatie server gebruik ik Glassfish 3 i.c.Netbeans 6.8. Heb een simpele REST applicatie mbv deze tutorial. De hello world werkt goed maar nu zie ik dat bij elke REST query een nieuwe instantie wordt gemaakt van het object. Hierdoor zal de (nogal grote) index elke keer worden ingeladen. Is het mogelijk via een andere manier dat deze maar eenmalig wordt ingelezen?

[rrrandy]

Misschien is het singleton pattern wat je zoekt?

[Creepy]

Ja dat is mogelijk............

.....

maar daar zat je vast niet op te wachten De tutorial is zo kaal dat we daar echt niet aan af kunnen leiden hoe jij nu je class instantieert op het moment dat er een request binnen komt. Qua techniek hoeft dat overigens helemaal niet verschillend te zijn t.o.v. je SOAP variant. Het blijft een request op een service en die levert een reponse op. Of dat nu SOAP, REST, GET, POST, <whatever> is maakt uiteraard geen verschil. Er zijn een hoop manieren om data te cachen en aangezien je een java applicatie draait is het echt een kleine moeite om een instantie van een class in leven te houden.

Dus hoe zou je dat zelf doen? Heb je al wat geprobeerd?

[ Voor 26% gewijzigd door Creepy op 29-12-2009 21:18 ]

[Red devil]

Creepy schreef op dinsdag 29 december 2009 @ 21:16:
Ja dat is mogelijk............

.....

maar daar zat je vast niet op te wachten De tutorial is zo kaal dat we daar echt niet aan af kunnen leiden hoe jij nu je class instantieert op het moment dat er een request binnen komt. Qua techniek hoeft dat overigens helemaal niet verschillend te zijn t.o.v. je SOAP variant. Het blijft een request op een service en die levert een reponse op. Of dat nu SOAP, REST, GET, POST, <whatever> is maakt uiteraard geen verschil. Er zijn een hoop manieren om data te cachen en aangezien je een java applicatie draait is het echt een kleine moeite om een instantie van een class in leven te houden.

Dus hoe zou je dat zelf doen? Heb je al wat geprobeerd?

Eigenlijk hoefde ik voor de SOAP variant niet veel te doen, de klasse die de SOAP requests afhandelde werd namelijk maar keer aangemaakt . Was dus toen snel klaar, want tijdens initiatie handelde ik het inladen af en voila klaar. Nu zag ik alleen dat een dergelijke REST klasse opnieuw werd aangemaakt. Hoe zou jij het dan doen?

[Nick_S]

Je zou kunnen kijken naar het singleton pattern wat al eerder genoemd is. Dit kan dan op meerdere manieren geimplementeerd worden: met een static variabele (met eventueel lazy initialization, maar let dan op multithreading) of met een dependency framework als Guice of Spring.

[Verwijderd]

Misschien is dit een interessante video (van de JEE 6 en glassfish 3) die over REST implementaties gaat.

http://link.brightcove.co...2637001?bctid=57554015001

(BTW: je moet wel een account hebben tot java.sun.com)

[ Voor 13% gewijzigd door Verwijderd op 30-12-2009 11:13 . Reden: extra info ]

[Bl4ckviper]

Je kan natuurlijk ook met JCS (Java Chaching System) de boel cachen..

Gebruiken wij hier ook zodat we niet iedere call hoeven te doen.. Dit kan je configureren wanneer erbij voorbeeld wel weer een nieuwe lijst/index opgehaald kan worden.

Wat wij bijvoorbeeld doen is het cachen van een lijst met plaatsen je geeft aan middels aop welke aanroep in de cach moet.

XML:

     <bean name="plaatsenCache" class="mijn.package.cache.JCSCacheRegion" >
        <property name="regionName" value="plaatsen" />
        <property name="maxElements" value="1000" />
        <property name="maxLifeSeconds" value="3600" />
        <property name="shrinkerIntervalSeconds" value="60" />
    </bean>

<aop:config>
         <aop:aspect ref="plaatsenCache">
            <aop:around pointcut="execution(* <package>.service.haalPlaatsnamenOp(..))" method="cache" />
        </aop:aspect>
</aop:config>

[Nick_S]

Caching is inderdaad ook nog een optie, maar dan moet je ook gaan nadenken over cache invalidatie. Dit kan door middel van een timeout, inactivity maar ook door events. (Dat hebben we gedaan bij een klant dmv. JMS berichten die onze data repository uitzond, konden we allerlei documenten en transformaties afhankelijk van die documenten cachen, waardoor je app razendsnel word, maar toch gevoelig blijft voor wijzigingen in je data)

Maar laat de TS eerst maar kijken naar hoe een Singleton op te zetten, uitgebreidde caching komt wel als snelheid echt een probleem wordt.

vv Nep-tweakert!

[Red devil]

Allemaal erg bedankt voor nuttige tips, ga zsm uitproberen. Oliebollen bakken heeft op dit moment eventjes de hoogste prioriteit

[Red devil]

Nick_S schreef op dinsdag 29 december 2009 @ 23:42:
Je zou kunnen kijken naar het singleton pattern wat al eerder genoemd is. Dit kan dan op meerdere manieren geimplementeerd worden: met een static variabele (met eventueel lazy initialization, maar let dan op multithreading) of met een dependency framework als Guice of Spring.

Nu heb ik de singleton pattern geprobeerd, is in principe dezelfde optie die in de tutorial stond (alleen wordt ie daar iets anders genoemd). Maar geen succes.

Dit is de simpele helloworld (die bij elke REST get opnieuw wordt aangemaakt):

Java:

@Path("helloworld")
public class HelloWorld2 {
    @Context
    private UriInfo context;

    /** Creates a new instance of HelloWorld2 */
    public HelloWorld2() {
        System.out.println("HelloWorld2 is being initiated!");
    }

    /**
     * Retrieves representation of an instance of helloWorld.HelloWorld2
     * @return an instance of java.lang.String
     */
    @GET
    @Produces("text/html")
    public String getHtml() {
        return "<html><body><h1>Hello, World!!</body></h1></html>";
    }


    /**
     * PUT method for updating or creating an instance of HelloWorld2
     * @param content representation for the resource
     * @return an HTTP response with content of the updated or created resource.
     */
    @PUT
    @Consumes("text/html")
    public void putHtml(String content) {
    }
}

Dit is de code die de Lucene index inlaadt, zou ontzettend veel resources gaan kosten dan, hoeft dus maar 1 keer.

Java:

 void initializeReader() {
        FSDirectory directory;
              try {
             directory = FSDirectory.getDirectory("D:\\data\\Index");
            searcher = new IndexSearcher(directory);
              } catch (IOException ex) {
            ex.printStackTrace();
        }
    }

Ik snap niet precies wat je bedoelt om dit alles in een static variable te proppen. Iemand nog een idee?

[Nick_S]

Nu heb ik de singleton pattern geprobeerd

Volgende keer graag wat code laten zien, en beschrijven wat er niet lukt.

Je classloader laadt je class files en doet dit maar 1 keer per JVM instantie (hier zijn uitzonderingen op, maar we houden het even simpel). Je applicatie server maakt instanties aan van deze class voor het afhandelen van requests.

Bij servlets/webservices wordt er in principe maar 1 instantie aan gemaakt voor het afhandelen van requests.

Blijkbaar wordt er door de REST implementatie 1 instantie per request aangemaakt. Aangezien jij je IndexSearcher als instantie variabele hebt gedeclareerd, zal deze voor elk request opnieuw aangemaakt worden, hetgeen je dus niet wilt.

De simpelste Singleton bereik je door een statische variabele zonder lazy initialization.

Java:

@Path("helloworld")
public class HelloWorld2 { 
    private static final Searchable searcher = initializeSearcher();

    private static Searchable initializeSearcher() {
        try {
             FSDirectory directory = FSDirectory.getDirectory("D:\\data\\Index");
             searcher = new IndexSearcher(directory);
        } catch (IOException ex) {
            throw new IllegalStateException("Could not initialize searcher.", ex);
        } 
    }
}

Voor uitgebreidere Singleton implementaties of dependency injection kun je met google een hoop vinden, maar ik hoop dat dit je iets op weg helpt.

[ Voor 5% gewijzigd door Nick_S op 04-01-2010 16:59 ]

[Red devil]

Nick_S schreef op maandag 04 januari 2010 @ 16:57:
[...]

Voor uitgebreidere Singleton implementaties of dependency injection kun je met google een hoop vinden, maar ik hoop dat dit je iets op weg helpt.

Het werkt als een tiet Nick_S, zenks a lot

[Nick_S]

Red devil schreef op dinsdag 05 januari 2010 @ 16:25:
[...]


Het werkt als een tiet Nick_S, zenks a lot

Ja dat weet ik. Ik heb het zelf geschreven. Maar weet je nu ook wat het doet en waarom het het doet?

[Red devil]

Nick_S schreef op dinsdag 05 januari 2010 @ 16:37:
[...]

Ja dat weet ik. Ik heb het zelf geschreven. Maar weet je nu ook wat het doet en waarom het het doet?

Lol, als statische variabele zonder lazy initialization zal de IndexReader maar 1 keer worden geinitialiseerd. Of zoiets?

[Nick_S]

Red devil schreef op dinsdag 05 januari 2010 @ 17:04:
[...]


Lol, als statische variabele zonder lazy initialization zal de IndexReader maar 1 keer worden geinitialiseerd. Of zoiets?

Yep, nog even een waarschuwing. Als je straks een tweede REST service of Webservice gaat toevoegen, wil je dan je indexer nog een keer maken of wil je deze ene instantie gaan delen? (Ik hoef geen antwoord maar denk er maar even over na)