Announcement Announcement Module
Collapse
No announcement yet.
Suggestion Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Suggestion

    I would like to know your opinion about an architectural design that I have to implement. This is the situation:

    - Our software runs in a datacenter (SaaS) and our costumers have a client software installed.
    - That client software connects to our datacenter and sends a request through a web service.
    - Client receives a confirmation that a message arrived.
    - When processing is done, datacenter sends a message to the client software.
    On the server side:
    - When datacenter receives a message (via web service) from client, that message is placed in a queue, waiting for execution.
    - Several components will process that message, and each component has its own and different time to complete the execution, so the whole process is assynchronous.

    We are using ServiceMix with AMQ to accomplish these tasks, but we are having a lot of problems as: performance issues, messages that are lost, too many threads literaly killing each other. In resume, the whole architecture sucks and it is creating serious problems with our customers.
    Our chef architect is building a new application based on EJB message driven beans and JMS. I donīt like that concept, I am a Spring User for a long time, and I prefer the "Spring Way" to do stuff, but I never needed something like that, my applications were always typical web applications using spring mvc, beans and others.
    So my question is: what do you think that would be a good solution for our problem if we decide to use Spring? Spring Modules? Spring Batch?

    Thanks to everyone who is willing to help and sorry for my poor english.

  • #2
    There are not enough info to answer your question -
    what is a message rate (msgs/sec), how complicated processing is (I mean not an current implementation complexity, but "inherent" complexity). Which processing time is acceptable for a message? ...

    I seriously doubt that EJB-based solution would be any better. Concernig JMS - AMQ (if you have mean ActiveMQ) is one of the JMS implementations, do you plan to use some other with EJB?

    As for me, I would firstly look if simple solution would not suffice - namely, synchronous one.

    As for message losses, first simply recheck ActiveMQ configuration and usage mode.
    Originally posted by bosnic View Post
    I would like to know your opinion about an architectural design that I have to implement. This is the situation:

    - Our software runs in a datacenter (SaaS) and our costumers have a client software installed.
    - That client software connects to our datacenter and sends a request through a web service.
    - Client receives a confirmation that a message arrived.
    - When processing is done, datacenter sends a message to the client software.
    On the server side:
    - When datacenter receives a message (via web service) from client, that message is placed in a queue, waiting for execution.
    - Several components will process that message, and each component has its own and different time to complete the execution, so the whole process is assynchronous.

    We are using ServiceMix with AMQ to accomplish these tasks, but we are having a lot of problems as: performance issues, messages that are lost, too many threads literaly killing each other. In resume, the whole architecture sucks and it is creating serious problems with our customers.
    Our chef architect is building a new application based on EJB message driven beans and JMS. I donīt like that concept, I am a Spring User for a long time, and I prefer the "Spring Way" to do stuff, but I never needed something like that, my applications were always typical web applications using spring mvc, beans and others.
    So my question is: what do you think that would be a good solution for our problem if we decide to use Spring? Spring Modules? Spring Batch?

    Thanks to everyone who is willing to help and sorry for my poor english.

    Comment


    • #3
      Thanks al0 for reply

      thanks for reply. I can give you more details:

      - Today we are dealing with 100.000 request per day, but that number will increase, we are expecting 1M/day very soon.
      - The processe CAN NOT be synchronous because in the middle of our processing we contact some government servers (we are in Brazil) and than we wait for their answer. If they are off-line, we have to re-try 3 times. If they continue off-line, than we have a specific emergency use case to acomplish.
      - Active MQ is a bad software, and thatīs not only us that think that way. I know that there is a lot of configuration issues, but I like Spring solutions, where default configuration is enough in many cases. We allready tried inumerous different configurations, and there is allways some kind of problem. Allways.
      - The idea of using EJB MDB is from our chefe architect, but I am trying to present some other kind of solution, preferencially, Spring based solution.
      Some other questions that you made:
      - The processing is complex, performance is important but not the main goal. In an ideal scenario, we finish a process in about 2 minutes (generating an PDF file at the end), and that amount of time is very acceptable for our customers. The problem is not the speed, but the confiability of solution. When government servers are down, the whole process can take 10 minutes or more. Our costumers are fine with that. but they are not fine with sending a message and the message is simply lost in some point. We are thinking about putting whole messaging control in a database, because performance is not an issue. We prefer less performance and the confiablity of a good relational database implementation then a fast solution that we cannot trust.

      Comment


      • #4
        Yes, you have really compelling reason to be asynchronous (rather rare case).

        Concerning AqtiveMQ - I agree that it may be not so good, but you may as well try to replace it with some other JMS implementation - without change of the whole structure of the your software. You may wish take look on QPID (http://qpid.apache.org/).

        I have not first-hand experience with it, but my colleagues from other department of the company for which I work, have replaced ActiveMQ it their system with QPID and are very satisfied with results.

        Regards,
        Oleksandr

        Originally posted by bosnic View Post
        thanks for reply. I can give you more details:

        - Today we are dealing with 100.000 request per day, but that number will increase, we are expecting 1M/day very soon.
        - The processe CAN NOT be synchronous because in the middle of our processing we contact some government servers (we are in Brazil) and than we wait for their answer. If they are off-line, we have to re-try 3 times. If they continue off-line, than we have a specific emergency use case to acomplish.
        - Active MQ is a bad software, and thatīs not only us that think that way. I know that there is a lot of configuration issues, but I like Spring solutions, where default configuration is enough in many cases. We allready tried inumerous different configurations, and there is allways some kind of problem. Allways.
        - The idea of using EJB MDB is from our chefe architect, but I am trying to present some other kind of solution, preferencially, Spring based solution.
        Some other questions that you made:
        - The processing is complex, performance is important but not the main goal. In an ideal scenario, we finish a process in about 2 minutes (generating an PDF file at the end), and that amount of time is very acceptable for our customers. The problem is not the speed, but the confiability of solution. When government servers are down, the whole process can take 10 minutes or more. Our costumers are fine with that. but they are not fine with sending a message and the message is simply lost in some point. We are thinking about putting whole messaging control in a database, because performance is not an issue. We prefer less performance and the confiablity of a good relational database implementation then a fast solution that we cannot trust.

        Comment

        Working...
        X