1 2 Previous Next 15 Replies Latest reply on Jan 15, 2008 12:56 PM by Mark Little

    ServiceInvoker : choosed EPR

    Noel Rocher Apprentice

      A useful info would be to have the choosed EPR used to deliver a message by the ServiceInvoker (sync & async).

      Do you see any pbs to enter a feature request ?

        • 1. Re: ServiceInvoker : choosed EPR
          Tom Fennelly Master

          You should be able to control the selection of the EPR through setting of the "core":"org.jboss.soa.esb.loadbalancer.policy" property in jbossesb-properties.xml. This property specifies a org.jboss.soa.esb.addressing.EPR.LoadBalancePolicy implementation, which is used to select the EPRs to be used and the order in which hey are to be tried. The default impl use is org.jboss.soa.esb.listeners.ha.FirstAvailable (and some others are available out of the box), but you can implement your own.

          One thing we should probably support here (and you can create a JIRA feature request for) is the ability to set this policy on a per ServiceInvoker instance basis. At the moment it's global.

          • 2. Re: ServiceInvoker : choosed EPR
            Noel Rocher Apprentice

            I'm talking about having a way to know which EPR is choosen from the client code that is using the ServiceInvoker.deliverXxxx()

            • 3. Re: ServiceInvoker : choosed EPR
              Tom Fennelly Master

              Right, well in that case, you need to be able to set the policy on the ServiceInvoker instance.

              • 4. Re: ServiceInvoker : choosed EPR
                Mark Little Master

                 

                "noel.rocher@jboss.com" wrote:
                I'm talking about having a way to know which EPR is choosen from the client code that is using the ServiceInvoker.deliverXxxx()


                "Know" in what way? Debug messages? Programmatic? What do you want and why?

                • 5. Re: ServiceInvoker : choosed EPR
                  Noel Rocher Apprentice

                  as a return parameter for deliverAsync (instead of "void"),
                  for deliverSynch, I think I can find it in the reply message (correct?)

                  This will be used for home made tracing purpose.

                  • 6. Re: ServiceInvoker : choosed EPR
                    Tom Fennelly Master

                     

                    "noel.rocher@jboss.com" wrote:
                    as a return parameter for deliverAsync


                    Oooooo... no thanks... not as the return value to deliverAsync. This is where a proper execution context on the pipeline (not message context) would be useful.

                    "noel.rocher@jboss.com" wrote:
                    This will be used for home made tracing purpose.


                    You should be able to create a dedicated appender for this in yer log4j config and have all ServiceInvoker logs feed into it and into a seperate file (or whatever).


                    • 7. Re: ServiceInvoker : choosed EPR
                      Mark Little Master

                       

                      "noel.rocher@jboss.com" wrote:
                      as a return parameter for deliverAsync (instead of "void"),
                      for deliverSynch, I think I can find it in the reply message (correct?)

                      This will be used for home made tracing purpose.


                      Cough cough hack hack splutter splutter cough.

                      ;-)

                      • 8. Re: ServiceInvoker : choosed EPR
                        Mark Little Master

                         

                        "tfennelly" wrote:
                        "noel.rocher@jboss.com" wrote:
                        as a return parameter for deliverAsync


                        Oooooo... no thanks... not as the return value to deliverAsync. This is where a proper execution context on the pipeline (not message context) would be useful.


                        I'd still like to understand the *why*.

                        Typically (and for very good reasons) when using replica groups the client doesn't know who serviced the request *unless* the replica identifies itself in the response. (Which you can do out-of-the-box with the ESB anyway).

                        • 9. Re: ServiceInvoker : choosed EPR
                          Tom Fennelly Master

                           

                          "mark.little@jboss.com" wrote:
                          Typically (and for very good reasons) when using replica groups the client doesn't know who serviced the request *unless* the replica identifies itself in the response. (Which you can do out-of-the-box with the ESB anyway).


                          Well I'm not sure about noel's reason, but I can see it being useful to developers working on the ESB as a way of seeing "what's happening" e.g. which transport was used etc... for debug purposes. Sure, I wouldn't see this as being something used in production.

                          • 10. Re: ServiceInvoker : choosed EPR
                            Noel Rocher Apprentice

                             

                            "tfennelly" wrote:
                            "mark.little@jboss.com" wrote:
                            Typically (and for very good reasons) when using replica groups the client doesn't know who serviced the request *unless* the replica identifies itself in the response. (Which you can do out-of-the-box with the ESB anyway).


                            Well I'm not sure about noel's reason, but I can see it being useful to developers working on the ESB as a way of seeing "what's happening" e.g. which transport was used etc... for debug purposes. Sure, I wouldn't see this as being something used in production.


                            Exactly for this : "seeing what's happening".
                            Maybe only more logging in ServiceInvoker is enough

                            • 11. Re: ServiceInvoker : choosed EPR
                              Tom Fennelly Master

                               

                              "noel.rocher@jboss.com" wrote:
                              Maybe only more logging in ServiceInvoker is enough


                              +1

                              • 12. Re: ServiceInvoker : choosed EPR
                                Noel Rocher Apprentice

                                Forget about this, the message contains all necessary info after the invocation :

                                sendesb:
                                 [echo] Runs Test ESB Message Sender
                                 [java] >>>>>>>> MESSAGE (before) : message: [ JBOSS_XML ]
                                 [java] header: [ ]
                                 [java] context: [ ]
                                 [java] body: [ byte[]: Hello World - Straight to ESB listener - no Gateway, objects: {org.jboss.soa.esb.message.content.bytes=[B@1fdc96c} ]
                                 [java] fault: [ ]
                                 [java] attachments: [ Named:{}, Unnamed:[] ]
                                 [java] properties: [ {} ]
                                
                                
                                 [java] >>>>>>>> MESSAGE (after) : message: [ JBOSS_XML ]
                                 [java] header: [ To: JMSEpr [ PortReference < <wsa:Address jms://localhost/queue/quickstart_helloworld_Request_esb/>, <wsa:ReferenceProperties jbossesb:java.naming.factory.initial : org.jnp.interfaces.NamingContextFactory/>, <wsa:ReferenceProperties jbossesb:java.naming.provider.url : jnp://127.0.0.1:1099/>, <wsa:ReferenceProperties jbossesb:java.naming.factory.url.pkgs : org.jboss.naming:org.jnp.interfaces/>, <wsa:ReferenceProperties jbossesb:destination-type : queue/>, <wsa:ReferenceProperties jbossesb:specification-version : 1.1/>, <wsa:ReferenceProperties jbossesb:connection-factory : ConnectionFactory/>, <wsa:ReferenceProperties jbossesb:persistent : true/>, <wsa:ReferenceProperties jbossesb:acknowledge-mode : 1/>, <wsa:ReferenceProperties jbossesb:type : urn:jboss/esb/epr/type/jms/> > ] ]
                                 [java] context: [ ]
                                 [java] body: [ byte[]: Hello World - Straight to ESB listener - no Gateway, objects: {org.jboss.soa.esb.message.content.bytes=[B@1fdc96c} ]
                                 [java] fault: [ ]
                                 [java] attachments: [ Named:{}, Unnamed:[] ]
                                 [java] properties: [ {} ]
                                 [java] >>>>>>>> TO (after) : JMSEpr [ PortReference < <wsa:Address jms://localhost/queue/quickstart_helloworld_Request_esb/>, <wsa:ReferenceProperties jbossesb:java.naming.factory.initial : org.jnp.interfaces.NamingContextFactory/>, <wsa:ReferenceProperties jbossesb:java.naming.provider.url : jnp://127.0.0.1:1099/>, <wsa:ReferenceProperties jbossesb:java.naming.factory.url.pkgs : org.jboss.naming:org.jnp.interfaces/>, <wsa:ReferenceProperties jbossesb:destination-type : queue/>, <wsa:ReferenceProperties jbossesb:specification-version : 1.1/>, <wsa:ReferenceProperties jbossesb:connection-factory : ConnectionFactory/>, <wsa:ReferenceProperties jbossesb:persistent : true/>, <wsa:ReferenceProperties jbossesb:acknowledge-mode : 1/>, <wsa:ReferenceProperties jbossesb:type : urn:jboss/esb/epr/type/jms/> > ]
                                
                                


                                • 13. Re: ServiceInvoker : choosed EPR
                                  Mark Little Master

                                   

                                  "tfennelly" wrote:
                                  "mark.little@jboss.com" wrote:
                                  Typically (and for very good reasons) when using replica groups the client doesn't know who serviced the request *unless* the replica identifies itself in the response. (Which you can do out-of-the-box with the ESB anyway).


                                  Well I'm not sure about noel's reason, but I can see it being useful to developers working on the ESB as a way of seeing "what's happening" e.g. which transport was used etc... for debug purposes. Sure, I wouldn't see this as being something used in production.


                                  Why not add a meta-filter? By the time that's being called, the Message (including header) has been constructed so the To field is set. Plus this way you can do it dynamically.

                                  • 14. Re: ServiceInvoker : choosed EPR
                                    Tom Fennelly Master

                                    Oh ignore what I was saying there... it was a load of BS :-)

                                    1 2 Previous Next