Announcement

Collapse
No announcement yet.

RAM eating problem

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • RAM eating problem

    I'm having a bizarre problem... I am unable to create users or login with certain users. I was able to trigger a 503 error with this code. It is caused by php-fpm process being killed, and thus apache timing out.
    Code:
    $a = $this->getEntityManager()->getEntity('User','5ec4fc7cb73e789df'); // this is ok, the internal values array is populated correctly
    $b = $a->toArray(); // when this line is executed ram is swallowed
    which is quite strange. After some analysis it shows that when that user tries to log-in (or the above code is executed, or the API call for getting the user data is made by the frontend) the script will suddenly eat up all available ram.

    Also, I am able to login without problems with my administrator account, and some other account. It may be a database problem but when I duplicated the user row and changed their id the problem would persist...

    I'm not sure it depends on Espo yet, but I would like to know what you think about this yuri

    I am also working with cpanel support team to troubleshooting. Do you know any condition that could result in this wild memory allocation?
    I had a look at the toArray function and seems quite normal to me. Maybe there is some underhanded bug I am not seeing.
    Last edited by tothewine; 07-22-2020, 08:14 PM.

  • #2
    > Do you know any condition that could result in this wild memory allocation

    I've never encountered.

    Comment


    • #3
      The real strange thing is that installing and loading xdebug makes it go away so I can't even debug it properly... I can't wrap my head around the fact that only some specific accounts (none of which are admin) are unable to login. I think I will try changing the is_admin column in the database for one of the problem users and see if I can login by making them admin temporarily...

      Comment


      • #4
        is_admin is not supported field and will be removed in 6.0. Use type = 'admin' instead..

        Comment


        • tothewine
          tothewine commented
          Editing a comment
          thanks. will do

      • #5
        Well, in the end I found the cause... infinite recursion of the Entity->get() method for a specific password-like field (unencrypted write only, basically) that was using Entity->get('field') to get the original value...so basically it's this custom code's fault:

        Code:
        namespace Espo\Custom\Entities;
        class User extends \Espo\Entities\User {
        protected function _getTempCode(): string {
         $ret = $this->get('tempCode'); // infinite recursion (!)
        // some other processing using $ret happens here...
         if (!empty($ret)) return '*******'; else return $ret;
        }
        
        protected function _setTempCode($value): void {
        if ($value !== '*******') $this->setValue('tempCode', $value);
        }}
        Is there a "setValue" equivalent for reading bypassing hooks? I would like to suggest a "getValue" function for doing ->get but without hooking
        And is there a more proper way to make a field write-only?

        Comment


        • #6
          You can read directly from $valuesContainer property.

          Comment


          • tothewine
            tothewine commented
            Editing a comment
            perfect thank you
        Working...
        X