For the specific problem here the QOS would be addressed by retries with a
"reasonable" cap.

Are you thinking more broadly than the problem at hand (wire format
timeout). If so, this is a different topic
worth discussing in a separate thread.


On Fri, Feb 7, 2014 at 12:11 PM, Eddie Epstein (JIRA)
<[email protected]>wrote:

>
>     [
> https://issues.apache.org/jira/browse/UIMA-3605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894729#comment-13894729]
>
> Eddie Epstein commented on UIMA-3605:
> -------------------------------------
>
> How does JMS quality of service fit into this situation?
>
> > UIMA-AS gets "Wire format negotiation timeout" on connection.open()
> > -------------------------------------------------------------------
> >
> >                 Key: UIMA-3605
> >                 URL: https://issues.apache.org/jira/browse/UIMA-3605
> >             Project: UIMA
> >          Issue Type: Bug
> >          Components: Async Scaleout
> >    Affects Versions: 2.4.2AS
> >            Reporter: Jerry Cwiklik
> >            Assignee: Jerry Cwiklik
> >             Fix For: 2.5.0AS
> >
> >
> > It appears that under heavy network load UIMA-AS is getting "Wire format
> negotiation timeout" Exception when opening a connection to a broker.
> > The client side of AMQ is sending a frame containing its parameters to
> the server (broker). It reconciles clients params against its own and sends
> a reply  back to the client. The reply apparently never reaches the client
> causing the timer to pop (default=10secs) and an exception is thrown.
> > Attempt to extend the client timeout via
> wireFormat.maxInactivityDurationInitalDelay=60000 doesnt fix the problem.
> One possible explanation is that either the client wire format frame is not
> reaching the server or the server's reply doesnt reach the client. This may
> be due to a lost TCP packet.
> > Since the low level amq wire negotiation doesnt offer retry, the UIMA-AS
> may need implement a higher level retry around the connection open() logic.
> It should capture generic JMSException and check the associated description
> for "wire format ..." problem. In such case, the connection should be
> closed and reopened.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.1.5#6160)
>

Reply via email to