-
1. Re: ServiceInvoker : choosed EPR
tfennelly Jan 15, 2008 5:03 AM (in response to noel.rocher)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 Jan 15, 2008 7:18 AM (in response to 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 Jan 15, 2008 7:20 AM (in response to noel.rocher)Right, well in that case, you need to be able to set the policy on the ServiceInvoker instance.
-
4. Re: ServiceInvoker : choosed EPR
marklittle Jan 15, 2008 7:28 AM (in response to noel.rocher)"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 Jan 15, 2008 7:34 AM (in response to 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 Jan 15, 2008 7:57 AM (in response to noel.rocher)"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 Jan 15, 2008 7:58 AM (in response to noel.rocher)"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 Jan 15, 2008 7:59 AM (in response to noel.rocher)"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 Jan 15, 2008 8:03 AM (in response to noel.rocher)"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 Jan 15, 2008 8:46 AM (in response to 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 -
-
12. Re: ServiceInvoker : choosed EPR
noel.rocher Jan 15, 2008 9:33 AM (in response to 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 Jan 15, 2008 10:23 AM (in response to 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.
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 Jan 15, 2008 11:51 AM (in response to noel.rocher)Oh ignore what I was saying there... it was a load of BS :-)