evil side affect of -usernotifytime parameter - Forum - OpenEdge RDBMS - Progress Community

evil side affect of -usernotifytime parameter

 Forum

evil side affect of -usernotifytime parameter

This question is not answered

First of all I would like to say thank you to PSC for that parameter. It is a major step into making all schema changes online. We added a couple indexes online in Dev. All worked as expected.

After about 3-4 months of using that parameter in dev we moved it to production yesterday. Unfortunately as we found out that parameter prevents disconnecting the users from the database. So proshut -C disconnect user does not work. It sets the flag for the user to disconnect, but the user does not disconnect from the database. Same in promon option 8/1. We have a script that disconnects users with active transaction duration over 30 minutes. Script works well for us over 10 years. Yesterday we had users running transactions over 5-6 hours. As a result of that our .bi file start growing ... 5 GB, 10 GB, 12 GB fortunately I allocated 20 GB and have an other 30 GB free. But that is really not a nice position of DBA to see .bi grow. So we removed -usernotifytime and opened a Ticket # 00408890 with PTS

-usernotifytime is a dynamic parameter. I eventually did set it to zero in promon R&D 4/7/8 when we hit that problem. Unfortunately that did not affect the users that were already flagged to disconnect and refused to do so by the time of setting -usernotifytime to zero.

Progress 11.7.1

IBM AIX 7.1

Dmitri Levin

Alphabroder

All Replies
  • Just an example from db log that Dmitri shared with me:

    [2017/07/18@14:14:02.678-0400] P-36897196   T-1     I SHUT 1151: (-----) User 728 disconnect initiated
    [2017/07/18@14:14:02.679-0400] P-30212642   T-1     I BROKER  0: (-----) Sending signal 7 to user 728
    [2017/07/18@14:29:02.436-0400] P-30212642   T-1     I BROKER  0: (-----) Sending signal 7 to user 728
    [2017/07/18@14:29:02.558-0400] P-30212642   T-1     I BROKER  0: (-----) Sending signal 7 to user 728
    [2017/07/18@14:34:02.016-0400] P-30212642   T-1     I BROKER  0: (-----) Sending signal 7 to user 728
    [2017/07/18@14:34:02.141-0400] P-30212642   T-1     I BROKER  0: (-----) Sending signal 7 to user 728
    
    [2017/07/18@20:59:44.000+0000] P-45154680   T-258   I ABL   728: (-----) Protrace location: /path/to/protrace.45154680
    [2017/07/18@16:59:44.000-0400]
    
    [2017/07/18@17:04:02.573-0400] P-30212642   T-1     I BROKER  0: (-----) Sending signal 7 to user 728
    [2017/07/18@17:09:01.819-0400] P-30212642   T-1     I BROKER  0: (-----) Sending signal 7 to user 728
    [2017/07/18@17:09:01.948-0400] P-30212642   T-1     I BROKER  0: (-----) Sending signal 7 to user 728
    
    [2017/07/18@21:10:13.000+0000] P-45154680   T-258   I ABL   728: (562)   HANGUP signal received. 
    [2017/07/18@17:10:13.000-0400]
    
    [2017/07/18@17:19:01.372-0400] P-30212642   T-1     I BROKER  0: (-----) Sending signal 7 to user 728
    [2017/07/18@17:24:02.222-0400] P-30212642   T-1     I BROKER  0: (-----) Sending signal 7 to user 728
    [2017/07/18@17:24:39.623-0400] P-45154680   T-1     I ABL   728: (2252)  Begin transaction backout. 
    [2017/07/18@17:24:39.638-0400] P-45154680   T-1     I ABL   728: (2253)  Transaction backout completed. 
    [2017/07/18@17:24:39.639-0400] P-45154680   T-1     I ABL   728: (453)   Logout by <user> on /dev/pts/123. 
    
    

    protrace.45154680 contains:

    +++ID Node 0 Process 45154680 Thread 2
    +++STACK
    uttraceback : 0x0000001c
    uttrace_withsigid : 0x00000154
    drProTrace : 0x0000004c
    drSigDo1@AF44_10 : 0x00000078
    drSigDispatch : 0x00000250
    _p_nsleep : 0x00000010
    nsleep : 0x000000e4
    nanosleep : 0x000001f8
    utsleep@AF13_9 : 0x00000024
    rnNeedsAttnThread : 0x000000f0

    When the -usernotifytime is enabled the ABL processes seem to use two threads. The second thread is sleeping after disconnect.

  • That is definitely a bug and PTS should enter a bug for Progress development.

  • It will be fixed in next release.

    Dmitri Levin

    Alphabroder

  • Hi Dmitri, can you provide the defect number?
     
    Thanks,
      Marie
     
  • Never mind, I found it.