Re: [ebxmlms-general] Retry attempt/interval change - not reflect ed in mshconfig table?

[Patrick Y. <kc...@ce...>]

Hi,

Mal is right, to tune the retry count and retry interval for the ebMS 
reliable feature, one should set it up in the construct of the Request 
object. The settings modified in Steven's case is not for ebMS feature. 
Instead, it is used by the custom delivery handler to pump the received 
messages to the applications. ..p

Regards,
Patrick Yee
Center for E-Commerce Infrastructure Development

Making E-Commerce Everyday Commerce



Pattiarachi, Mal wrote:

> I'm not quite sure whether this is right but in my code, wherever I 
> register a listener with MSH (that is the architecture we use) we have 
> something along the following lines:
>  
>             mshReq = new Request(appContext, mshServerUrl, listener, 
> "http", //);
>                 Request.DEFAULT_RETRIES, 
> Request.DEFAULT_RETRY_INTERVAL, 
> Request.SYNC_REPLY_MODE_SIGNALS_AND_RESPONSE,
>                 Request.DEFAULT_MESSAGE_ORDER_SEMANTICS, 
> Request.DEFAULT_PERSIST_DURATION);
> For each place where you register MSH to point to your parnert's url, 
> I think you'll need to replace the Request.DEFAULT_RETRIES 
> and Request.DEFAULT_RETRY_INTERVAL (or equivalent) with the values 
> retrieved from the msh.properties.xml configuration file.
>  
> Sincerely,
> Mal
>
> ------------------------------------------------------------------------
> *From:* ebx...@li... 
> [mailto:ebx...@li...] *On Behalf Of 
> *Steven Herod
> *Sent:* Wednesday, 31 August 2005 9:13 AM
> *To:* ebx...@li...
> *Subject:* RE: [ebxmlms-general] Retry attempt/interval change - not 
> reflected in mshconfig table?
>
> No, I've had no feedback so far.
>  
> We've cleaned out the DB table and restarted app handler and hermes 
> server but we still seem to get the defaults, not the new ones we've 
> configured.
>  
> So, I'm going to have to read some source code it seems...
>  
> But surely somebody out there has modified the retry count and period????
>  
> The underlying problem we're trying to solve is a timeout on the first 
> transmission, by the time hermes re-attempts a transmission with its 
> default period of 2min 30sec its too late for our trading partner to 
> receive the message.
>
> ------------------------------------------------------------------------
> *From:* ebx...@li... 
> [mailto:ebx...@li...] *On Behalf Of 
> *Pattiarachi, Mal
> *Sent:* Wednesday, 31 August 2005 8:54 AM
> *To:* 'ebx...@li...'
> *Subject:* RE: [ebxmlms-general] Retry attempt/interval change - not 
> reflected in mshconfig table?
>
> Did you find an answer to this one Steven? Do you need to delete the 
> database and re-start the server?
>  
>
> ------------------------------------------------------------------------
> *From:* ebx...@li... 
> [mailto:ebx...@li...] *On Behalf Of 
> *Steven Herod
> *Sent:* Friday, 26 August 2005 2:47 PM
> *To:* ebx...@li...
> *Subject:* [ebxmlms-general] Retry attempt/interval change - not 
> reflected in mshconfig table?
>
> We've modified our msh.properties.xml file to add the section:
>  
>     <Delivery>
>       <RetryInterval>20000</RetryInterval>
>       <MaximumRetry>10</MaximumRetry>
>     </Delivery>
>   </MSH>
>  
> However, these new settings do not seem to be appearing in the 
> mshconfig table after we restart hermes or our application handler.
>  
> The values in the mshconfig table (C_RETRIES, C_RETRYINTERVAL) seem to 
> still be the defaults (2 and 150000).
>  
> Is this normal?    Should we expect to see a change in this table, or 
> has the setting become silently effective elsewhere?
>  
>  
>
> The information contained in this email and any attachments to it:
>
> (a) may be confidential and if you are not the intended recipient, any 
> interference with,
> use, disclosure or copying of this material is unauthorised and 
> prohibited; and
>
> (b) may contain personal information of the recipient and/or the 
> sender as defined
> under the Privacy Act 1988 (Cth). Consent is hereby given by the 
> recipient(s) to
> collect, hold and use such information and any personal information 
> contained in a
> response to this email, for any reasonable purpose in the ordinary 
> course of
> Ross Human Directions Limited business (including all of it's 
> subsidiaries), including forwarding this
> email internally or disclosing it to a third party. All personal 
> information collected by
> Ross Human Directions Limited will be handled in accordance with Ross 
> Human Directions Limited
> Privacy Policy. If you have received this email in error, please 
> notify the sender and delete it.
>
> (c) you agree not to employ or arrange employment for any candidate(s) 
> supplied in
> this email and any attachments without first entering into a 
> contractual agreement with
> Ross Human Directions Limited. You further agree not to divulge any 
> information contained in this document
> to any person(s) or entities without the express permission of Ross 
> Human Directions Limited
>