On Sat, Mar 28, 2009 at 1:44 PM, Jonas Buys <[email protected]> wrote: > > Hi, > > I have implemented a service that consumes notifications (i.e. > NotificationConsumer capability). > > But for each <Notify> message I see a <NotifyResponse>: > > <soapenv:Envelope > xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"; > xmlns:wsa="http://www.w3.org/2005/08/addressing";> > <soapenv:Header> > <wsa:To>http://www.w3.org/2005/08/addressing/anonymous</wsa:To> > <wsa:ReplyTo> > > <wsa:Address>http://www.w3.org/2005/08/addressing/none</wsa:Address> > </wsa:ReplyTo> > > <wsa:MessageID>urn:uuid:9CAC3C71040F9D76F4123824223414018</wsa:MessageID> > > <wsa:Action>http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/NotifyRequest</wsa:Action> > <wsa:RelatesTo > wsa:RelationshipType="http://www.w3.org/2005/08/addressing/reply";>uuid:138ee423-37af-c545-66bd-6f7cdaaece6a</wsa:RelatesTo> > </soapenv:Header> > <soapenv:Body> > <wsnt:NotifyResponse > xmlns:tns="http://axis2.platform.core.muse.apache.org"; > xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2"/> > </soapenv:Body> > </soapenv:Envelope> > > In WsnConstants.java I found: > // HACK: This is not defined by the standard, but we need something to > // send back to blocking clients > // > public static final QName NOTIFY_RESPONSE_QNAME = > new QName(NAMESPACE_URI, "NotifyResponse", PREFIX); > > 1. Can I disable the submission of these replies in any way?
Not that I'm aware of. What I would like to add is the ability to return a 204 NO_RESPONSE for http based environments (i.e. all default Muse isolation layers, not sure how it works with access though). This would have to wait until 2.3.0 as it breaks compatibility (i.e. we need to signal that no response is actually intended). > 2. Something else, didn't spot this in WS-BN spec: is there any way to enable > assured delivery for notifications? We are planning to use then for > fault-tolerant experiments in our lab. Suppose WS-RM could come in here? > Any suggestions? RM isn't supported by Muse :-<. To be honest if you are after fault tolerance you will have to add your own protocol on top, RM or otherwise, including heartbeats etc, the best solutions tend to vary with each actual use case.. > 3. I have a service that in its initializeCompleted() starts a thread to send > notifications every 10 seconds, but after a while - when the client program > (main) stops - messages stop flowing too. How can I make sure the service > will persist in sending messages in time? Log doesn't give any more info. > Subscription was made with null as time-out, so I should go on forever? Only if you don't destroy both the actual underlying resource and the subscription manually. Also note that you may be falling victim to Muse 270, which is only in head and the 270 tag, but proving that one way or the other is tough to do. To test it add extra logging to the sending thread to see if it at least thinks it should be sending still.
