Announcement Announcement Module
No announcement yet.
Use RMI to retrieve a 2MB file through stateless EJB Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Use RMI to retrieve a 2MB file through stateless EJB

    Hi Everyone:

    I hava a distributed system which consists of a Tomcat as web tier and a Jboss server hosts SLSB- Stateless Session EJB (making database connection etc). Tomcat and Jboss server resides on separated java virtual machines. We are forced to use RMI as communication protocol between Tomcat and Jboss.

    A manager of this project asked me to write some codes let a Plain Old Java Object in Tomcat container to retrieve a PDF file (as big as 2MB) from Jboss application serverís directory.

    I didnít think this is applicable through remote RMI -Stateless EJB method implementing remote home interface. My understanding of EJB is built on RMI. Through RMI, there is limited amount data can be serialized and transferred among virtual machines.

    It might still be doable through native RMI level programming with a mark/reset FileImputStream.

    Or I need to chop the PDF into a few small size object, then reassemble them into one file in Tomcat container

    But that is not a trivial job, plus I am not allowed to alert Tomcat source code and jboss source code.

    How can I convince the manager that his idea is not applicable? Or do your guys have solution for this scenario or suggestion for me?

  • #2
    Is there a reason not to use plain old http?


    • #3
      Originally posted by dejanp
      Is there a reason not to use plain old http?
      Company security police prohibited http communication between web DMZ and application server DMZ

      Here is code I implmented in Stateless Session EJB to retrieve the pdf file frome jboos serve to web container

      public InputStream getPDFByApplID ( String applID,String fileName, int bufferSize) throws IOException, EJBException{
      			 byte[] buffer = new byte[bufferSize];
      			 InputStream fis = new BufferedInputStream (new FileInputStream (fileName));
      			 return fis;
      It highly likely get out of menory error. just because if defined bufferSize is too big.

      But It is working for limited thread access ( web tier's POJOs call this method).

      Any good solutions can reduce the possibilites to out of menory error?


      • #4
        You could try ftp or scp or sftp then. Imo anything is better then trying to fit a sqare peg in a round hole. Yes, it will fit if you hammer it hard enough, but it's not going to be pretty to look at.


        • #5
          if you do something like this in your web tier and I assume you are sending the pdf file to the client. You should not have any OutOfMemory errors.

          Web Tier POJO

          bis = new BufferedInputStream(ejb.getPDFByApplID("a","a",0)) ;
          bos = new BufferedOutputStream(response.getOutputStream());

          //Read only small amount of data from the input stream
          byte[] data = new byte[1024];

          while(( != -1){
          bos.write(data,0,i); //write to the out stream
          bos.flush(); //flush to the client, it wont accumulate in memory


          Hope this helps


          • #6
            I think your code won't work.

            An EJB call can only return a serializable or a remote object. Your input stream is neither of these so it wont work.

            Your best bet in case you can't use http would be returning a byte array containing the whole file.


            • #7
              saadkhawaja's solution did not make use of EJBs but utilizes a HttpResponse.



              • #8
                I agree that the best protocol for transmiting files from an application server would be HTTP, but since his company policy prevents this i think he is stuck with using a RMI call sending a byte array.

                As long as your file is not bigger than 500k you should be safe. Anything bigger and the pain will come.


                • #9
                  Well, strictly speaking, http is also not built for the big file transfers. That's why we have ftp, sftp, scp etc.