aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes How to execute code just after your appserver started ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "How to execute code just after your appserver started ?" Watch "How to execute code just after your appserver started ?" New topic
Author

How to execute code just after your appserver started ?

Claude Moore
Ranch Hand

Joined: Jun 24, 2005
Posts: 468
    
    1

Hi guys,

I need advice on this topic: just after my appserver is started , I want to instantiate a class and run some method of it. Which approach would you suggest to follow to do that ? In the past, I remember I just included my "bootstrap" code in a static block within an EJB bean class, ensuring, via specific appserver conf, that at least one instance of that Ejb were instantiated immediately after startup. The whole thing worked but I wonder if there exist a better approach (mine was really an ugly workaround)...

Thank you in advance !
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1282

If you are using JEE 6 there's a nice alternative to do some bootstrapping. You can use an eagerly initialized singleton bean like this


Marco
Claude Moore
Ranch Hand

Joined: Jun 24, 2005
Posts: 468
    
    1

Thanks Mario for your advice,

unluckily at the moment I'm stucked at J2EE 1.4, so I cannot use your suggestion.

Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42277
    
  64
Does the app server contain a servlet container? If so, you could use a web app context listener class.


Ping & DNS - my free Android networking tools app
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30758
    
156

Or a servlet with the init on startup option set in the web.xml.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42277
    
  64
Jeanne Boyarsky wrote:Or a servlet with the init on startup option set in the web.xml.

IMO, that only makes sense if the initialization is closely tied to that particular servlet. Before context listeners existed this approach was used to perform app-wide initializations, but it should be considered obsolete now.
Claude Moore
Ranch Hand

Joined: Jun 24, 2005
Posts: 468
    
    1

Thank you guys,

my appserver actually contains both an Ejb and a Servlet (web) container. I think I need to be more explicit about what I'm trying to achieve: I've build a TCP client/server protocol using the excellent Netty library.. and I wish to embed it in my appserver. In a nutshell, I wrote a class that starts up a socket server (of course this server will listen to different ports with respect those appserver is bounded with), and of course I need to start that class without waiting for a "first request" from any client. Anyway I thought that init() method in a servlet was called the first time a request was made against that servlet..isn't so ? I never used Web app context listener... is it initialized just when an application is started ?

Thank you very much for your help....
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42277
    
  64
I thought that init() method in a servlet was called the first time a request was made against that servlet..isn't so ?

That's why Jeanne mentioned the "startup option", which causes the servlet to load when the web app starts, rather than when the first request is made.

I never used Web app context listener... is it initialized just when an application is started ?

Yes, when the servlet container starts the web apps, which is right after the servlet container starts.
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1282

Hi Claude,

i think the correct way to use socket communication and thread handling (which you probably need to have) inside a J2EE/JEE environment is to implement a JCA connector. This is an extension point of the plattform meant for such use cases. Honestly I've not yet done this for J2EE 1.4 but from a quick look at Google it should be possible as the JCA 1.5 specification was already there before JEE. Here are some links which describe how to build a JCA connector and you will find many more on the internet. You just have to get familiar with some J2EE API classes, interfaces and descriptors but beside this it shouldn't be too difficult.

http://code.google.com/p/jca-sockets/
http://www.javaworld.com/javaworld/jw-11-2001/jw-1121-jca.html
http://www.theserverside.com/news/1364656/Serve-It-Up-with-J2EE-14-Use-JCA-15-and-EJB-21-to-Extend-your-App-Server

Good luck!

Marco
Claude Moore
Ranch Hand

Joined: Jun 24, 2005
Posts: 468
    
    1

Ulf: thanks for explanations, are really precious for me.

Marco: thank you for your suggestion. To be quite honest, I was already a bit afraid of using a custom socket/thread handling within an appserver, and your post just enforced my feelings I may be on the wrong way.... I know that in a J2EE enviroment, usage of "spurious" threads is greatly discouraged, because appserver is a controlled enviroment and self-spawned threads may create problems. I'll study material you've suggested to me, and I think that a JCA solution would be really more clear (and portable). Anyway, since I'm not a real expert on Netty (I'm just starting up with it), I really have to investigate if such a solution is a feasible way to implement my own client-server protocol within an Appserver. At the moment, my application communicates with the server using http protocol as transport mechanism exchanging serialized data object. I'm just verifying, running some tests, if a socket-oriented protocol would be more efficient. For example I'm going to let me client use a persistent connection with remote server, not opening at releasing connections as now they're actually doing. I hope this work won't result in a totally wasting of my time.....
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1282

If a JCA connector is an option for your problem you should search for already existing examples on the internet. I remember that there were socket examples with Apache Mina and JBoss Netty. If you have to use a socket server I guess it's really the most compatible way to use JCA to get it running inside an application server. It *could* work to control thread handling etc. yourself from inside your application code but to my knowledge it's not a portable solution you can rely on inside an J2EE environment.

But depending on your needs and requirements there may be some other alternatives not mentioned here. You could for example create a standalone socket server and bridge the gap to J2EE with an integration solution like Apache Camel or Apache ServiceMix. If asynchronous communication is a valid option you could get away with Camel translating your socket protocol to JMS messages etc. Of course every additional framework and tool makes the solution also more complex at first. So it really all depends on you requirements and constraints.

Marco
Claude Moore
Ranch Hand

Joined: Jun 24, 2005
Posts: 468
    
    1

Thank you Marco,

I'll study how implementing a JCA solution.

By the way, what do you think about the idea of using a custom client-server protocol ?
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1282

By the way, what do you think about the idea of using a custom client-server protocol ?

Well, obvoiusly a custom solution may be precisely tailored to fit your needs. Existing frameworks like Netty or Mina help you to focus on high-level details and give you a robust foundation to avoid problems. As I said, depending on your requirements and constraints this may be the only option you have (regardless if you package it inside a JCA connector).

On the other hand this is clearly more work to do, more code to implement, more things to get wrong. At first glance it's hard to imagine use cases where the myriads of networking protocols and frameworks existing today to integrate distributed systems wouldn't provide sufficient solution to your problem. But without knowing all the details it's hard to tell what would be the "right" way. I guess you'll have to decide on your own.

Of course feel free to discuss your thoughts with us here on Coderanch

Marco
Claude Moore
Ranch Hand

Joined: Jun 24, 2005
Posts: 468
    
    1

In a nutshell I'd like to build a custom remoting protocol, in which I exchange serialized Java class as business data. I may use EJB remoting but that's very application server specific, so I'd redistribute client jars to make remoting work. Moreover, EJB remoting over WAN has very bad performances, expecially with high latency.
I considered Spring remoting, but as far as I understood, it basically uses Http as transport layer; and currently I'm already using http transport for my own protocol, so I don't think I'd achieve better performance ....

I'd like to experiment a bit with netty, and use a direct socket connection. I think this way I would achive minimum overhead (with respect to http based remoting)....

I'm very glad that here at JavaRanch one can discuss even about abstract matters like protocols....
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1282

If your client and server are both implemented in Java maybe remoting over RMI or IIOP is the easiest and most Java-like way to connect the systems. But I agree that there may be better solutions to connect systems over WAN.

HTTP is probably one of the most used transport protocols to connect distributed systems over the internet. It's very robust, easy to use, it runs on almost all platforms and it's supported by any well-known programming language. Do you know for sure that the HTTP protocol itself is the root cause of the performance problems you are experiencing? What data format are you using to serialize you data? Text, XML, JSON, ...? Is too much traffic in respect to the overall data volume a problem? Is the communication between client and server very chatty, i.e. do you have many round trips between client and server?

If it's really the overhead in traffic of a text based protocol like HTTP which makes you trouble you should at least consider existing binary formats like Google's protocol buffers or BSON to represent your data. If you have too many round trips between client and server which cause high latency you should probably redesign the way your client and server communicate in general to reduce network latency that way.

I'm still unsure what exactly you are trying to achieve besides data exchange so please don't take my advices and thoughts to serious!

Marco
Claude Moore
Ranch Hand

Joined: Jun 24, 2005
Posts: 468
    
    1

Well Marco, it would be long to explain all that lies under the hood, anyway I think you guessed well at least two problems: the fact that client-server communication is really chatty, and the fact that client and server do exchange a fair good quantity of data each other. Anyway, in different use cases it would impossibile to adopt a Session Facade pattern, for example: in a tipical scenario an user may search for a list of items, and for each item may choose to explode details. Getting all details of all possibile items selected may be not trivial, so normally I let the user select an item and, on explicit request, I load with a separate request other data regarding that item.

I cannot be sure of course that Http is by itself the main bottleneck... data are sent as base64 encoded binary stream, and are Gzipped to reduce at the max payload on the Net.
I use Apache HttpClient, while on server side request are handled by a Servlet which interpretes attached data and fulfills requests. I though that I wasn't using at the best Apache libraries, so I tried converting some pieces of code using JAX-WS, the result was even worse the before.

I can ensure you that using RMI over a WAN is dreadful. I run only few test but I immediately realized it was not viable way. Now I came to the conclusion I just have to play with a low-level protocol for a while. You're right saying that with a custom protocol there are a lot of things that may go wrong. I know and I agree with you. But I think that with a simple prototype with no real server-side computational work, just a pass-around of data, I can bring to the limit my client's speed capabilities. And with Http Client I think I could not be really free on doing whatever I want, I'm tied up to protocol specification.

Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1282

That sound like you already did your homework and you are well ware of the potential problems and solutions!

Anyway, from what I know so far about your problem it seems that you should go for a compact data format and try to transport as many data as possible with the least number of round trips between client and server, right?

If the size of the data is the bigger problem a binary format (like the said BSON or Protocol Buffers) will probably be the best you can get and certainly more compact than base64 encoded data. If performance suffers from high latency and the number of calls to the serve you will have to figure out a way to package more data into less response packets. Maybe it is a waste of traffic but still more efficient to prefetch some data in advance so that you don't need to call back to the server if the client needs that data?

Marco
Claude Moore
Ranch Hand

Joined: Jun 24, 2005
Posts: 468
    
    1

Marco Ehrentreich wrote:That sound like you already did your homework and you are well ware of the potential problems and solutions!


Thanks for that; more simply, it's just time to begin optimizing overall behaviour....

Marco Ehrentreich wrote:
Anyway, from what I know so far about your problem it seems that you should go for a compact data format and try to transport as many data as possible with the least number of round trips between client and server, right?
If the size of the data is the bigger problem a binary format (like the said BSON or Protocol Buffers) will probably be the best you can get and certainly more compact than base64 encoded data. If performance suffers from high latency and the number of calls to the serve you will have to figure out a way to package more data into less response packets. Maybe it is a waste of traffic but still more efficient to prefetch some data in advance so that you don't need to call back to the server if the client needs that data?


And that's the other side of the problem. Of course there are factors that you can't optimize at all and you need to deal with them as they are, like network latency or bandwith... So reducing size of data passed around it's a good idea to get things work better. You mentioned Protocol Buffers, and some time ago I gave them a try. The problem is that basically you need a specific "handler" for each "message" you're going to exchange. I'm currently exchanging JavaBeans, and at the moment i've a one-to-one relationship between dataobjects and DBMS tables (those javabeans actually rephresent data on my db). Since we're dealing with more than 1,000 tables, protocol buffers seemed unpracticable.

Thank you for your advice!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: How to execute code just after your appserver started ?