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

    ServiceInvoker : choosed EPR

    noel.rocher

      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
          tfennelly

          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

            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
              tfennelly

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

              • 4. Re: ServiceInvoker : choosed EPR
                marklittle

                 

                "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

                  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
                    tfennelly

                     

                    "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
                      marklittle

                       

                      "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
                        marklittle

                         

                        "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
                          tfennelly

                           

                          "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

                             

                            "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
                              tfennelly

                               

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


                              +1

                              • 12. Re: ServiceInvoker : choosed EPR
                                noel.rocher

                                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
                                  marklittle

                                   

                                  "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
                                    tfennelly

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

                                    1 2 Previous Next