Re: [PATCH] dlr retries

"Nikos Balkanas" <[email protected]>
Newsgroups gmane.comp.mobile.kannel.devel
Message-ID <002c01ca596d$a16b6dc0$02b2a8c0@tardis>
Dear Alex,

Have you been able to check on this?

BR,
Nikos
  ----- Original Message ----- 
  From: Alejandro Guerrieri 
  To: Nikos Balkanas 
  Cc: Kannel Devel 
  Sent: Sunday, October 25, 2009 2:42 PM
  Subject: Re: [PATCH] dlr retries


  I agree it's not the cleanest solution, but get the job done when needed.


  Alex, do you think of a better way to handle it, architecturally speaking?

  Regards,

  --
  Alejandro Guerrieri
  [email protected]






  On 25/10/2009, at 12:08, Nikos Balkanas wrote:


    Well it introduces a performance delay, probably to all SMS, but it is configurable, and if you need it you've got to have it. Any chance to improve on it by putting the deliver_sm back into the queue instead of sleeping?

    +1

    BR,
    Nikos
      ----- Original Message -----
      From: Alejandro Guerrieri
      To: Kannel Devel
      Sent: Sunday, October 25, 2009 12:10 PM
      Subject: [PATCH] dlr retries


      Resubmitting this patch by popular demand ;)


      http://www.blogalex.com/archives/132


      Regards,

      --
      Alejandro Guerrieri
      [email protected]






      Begin forwarded message:


        From: Alejandro Guerrieri <[email protected]>
        Date: 2 de mayo de 2009 14:48:19 GMT+02:00
        To: Kannel Devel <[email protected]>
        Subject: [PATCH] dlr retries


        Hi,

        This patch implements an "sleep and retry" when calling dlr_get(). This aims to solve the problem we were having with dlr's arriving before the row is inserted.

        2 new core parameters are defined:

        dlr-retry-count -> How many times do we attempt to fetch the dlr? Default: 1
        dlr-retry-delay -> How many milliseconds do we sleep before retrying? Default: 0

        So, if you don't set these parameters the behaviour remains as it was before patching. However, if you, for example, set:

        dlr-retry-count = 3
        dlr-retry-delay = 200

        Kannel will try 3 times in total (the original one plus 2 more), pausing 200ms (0.2 seconds) before each attempt. If after the third attempt the DLR's still missing, Kannel will display a warning as usual.





--------------------------------------------------------------------------






        Regards,
        --
        Alejandro Guerrieri
        [email protected]









--------------------------------------------------------------------------



      Resubmitting this patch by popular demand ;)

      http://www.blogalex.com/archives/132

      Regards,
      --
      Alejandro Guerrieri
      [email protected]



      Begin forwarded message:

      > From: Alejandro Guerrieri <[email protected]>
      > Date: 2 de mayo de 2009 14:48:19 GMT+02:00
      > To: Kannel Devel <[email protected]>
      > Subject: [PATCH] dlr retries
      >
      > Hi,
      >
      > This patch implements an "sleep and retry" when calling dlr_get().  
      > This aims to solve the problem we were having with dlr's arriving  
      > before the row is inserted.
      >
      > 2 new core parameters are defined:
      >
      > dlr-retry-count -> How many times do we attempt to fetch the dlr?  
      > Default: 1
      > dlr-retry-delay -> How many milliseconds do we sleep before  
      > retrying? Default: 0
      >
      > So, if you don't set these parameters the behaviour remains as it  
      > was before patching. However, if you, for example, set:
      >
      > dlr-retry-count = 3
      > dlr-retry-delay = 200
      >
      > Kannel will try 3 times in total (the original one plus 2 more),  
      > pausing 200ms (0.2 seconds) before each attempt. If after the third  
      > attempt the DLR's still missing, Kannel will display a warning as  
      > usual.
      >
      >
      >
      >
      > Regards,
      > --
      > Alejandro Guerrieri
      > [email protected]
      >
      >
      >
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.