someone asked about this previously, and I think our resolution was to add more (client-side) trace info. this page describes an <init-param/> you can add to muse.xml to get the SOAP trace for the notification messages (bottom of the page):
http://ws.apache.org/muse/docs/2.1.0/manual/capabilities/wsn-sub.html if the trace doesn't have any extra info from the consumer, then it's not available - you'll need to look in any of the consumer's server-side log files to determine the error. let me know if you find any log info for that application. we don't have any plans for WS-RM (I think Axis2 does this), and I don't know much about it. the problem with making notifications 'reliable' is that the definition of 'reliable' is vague. TCP/IP is 'reliable', but if you try to access http://www.ibmmmmm.com, you still get an error. If 'reliable' means that the notification eventually gets to the consumer, we need to determine things like: 1. how do you know if a consumer is temporarily down (server rebooting) or never existed in the first place (wrong address)? 2. if it's temporary, how many times do you retry? 3. what's the interval of time in between? 4. since other notifications will be published during that time, we'll have to keep a queue while the first failed notification is re-tried. a. we'll need to configure the queue length so we don't eat up too much memory - when we hit the length, do we drop messages from the front (old messages) or the back (new messages)? b. how do you know when a notification is only relevant for the current time period ('server is rebooting, will be back up in 30 seconds') vs when it needs to be recorded by clients ('there's a new resource in the service group with EPR X')? how do you configure this? I'm sure there are other issues I've overlooked. As you can see, a lot of it depends on the semantics of the specific ws-resource(s). because of this, you might want to subclass SimpleSubscriptionManager and override the publish() method to perform the re-try logic that you need for your app. It may not be applicable for other people's manageable resource types, but hey, that's why we made it pluggable. Dan Christian Ewers <[EMAIL PROTECTED]> wrote on 01/30/2007 03:55:03 AM: > > Hi, > > I'm using WSRP change notifications like stated on > http://ws.apache.org/muse/docs/2.1.0 > /manual/how-to/publish-wsrp-notifications.html. > The problem is, that sometimes some of the notifications fail with a HTTP > 500 response and the "LastPublishFailed" message. But I can only see that > in the log-file and the faulty behavior of the system. And I'm not sure why > the consumer is not reachable at that moment. I couldn't find any exception > in the log-files. > Is their a way to get the fault at runtime to retry the notification? Or > do I have to extend the SimpleSubscriptionManager and handle the Fault by > myself? > Did anyone tried to use WS-ReliableMessageing with Muse? Could I define the > notifiactions to be "reliable"? > > Thanks, > Christian > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
