[gold-users] Problem with gcharge

Artem Harutyunyan Artem.Harutyunyan at cern.ch
Sat Oct 31 08:47:09 MDT 2009


Hi Scott,

I am using mySQL, and g_amount was of type 'float':

mysql> desc g_allocation;
+---------------------+---------------+------+-----+------------+-------+
| Field               | Type          | Null | Key | Default    | Extra |
+---------------------+---------------+------+-----+------------+-------+
| g_creation_time     | int(11)       | NO   |     | NULL       |       |
| g_modification_time | int(11)       | NO   |     | NULL       |       |
| g_deleted           | varchar(5)    | YES  |     | False      |       |
| g_request_id        | int(11)       | NO   |     | NULL       |       |
| g_transaction_id    | int(11)       | NO   |     | NULL       |       |
| g_id                | int(11)       | YES  |     | NULL       |       |
| g_account           | int(11)       | YES  |     | NULL       |       |
| g_start_time        | int(11)       | YES  |     | 0          |       |
| g_end_time          | int(11)       | YES  |     | 2147483647 |       |
| g_amount            | float         | YES  |     | NULL       |       |
| g_credit_limit      | float         | YES  |     | 0          |       |
| g_deposited         | float         | YES  |     | 0          |       |
| g_active            | varchar(5)    | YES  |     | True       |       |
| g_call_type         | varchar(1024) | YES  |     | Normal     |       |
| g_description       | varchar(1024) | YES  |     | NULL       |       |
+---------------------+---------------+------+-----+------------+-------+

I did:
mysql> alter table g_allocation modify g_amount double default NULL;
mysql> alter table g_allocation modify g_credit_limit double default 0;
mysql> alter table g_allocation modify g_deposited double default 0;

so now the table looks like this:
mysql> desc g_allocation;
+---------------------+---------------+------+-----+------------+-------+
| Field               | Type          | Null | Key | Default    | Extra |
+---------------------+---------------+------+-----+------------+-------+
| g_creation_time     | int(11)       | NO   |     | NULL       |       |
| g_modification_time | int(11)       | NO   |     | NULL       |       |
| g_deleted           | varchar(5)    | YES  |     | False      |       |
| g_request_id        | int(11)       | NO   |     | NULL       |       |
| g_transaction_id    | int(11)       | NO   |     | NULL       |       |
| g_id                | int(11)       | YES  |     | NULL       |       |
| g_account           | int(11)       | YES  |     | NULL       |       |
| g_start_time        | int(11)       | YES  |     | 0          |       |
| g_end_time          | int(11)       | YES  |     | 2147483647 |       |
| g_amount            | double        | YES  |     | NULL       |       |
| g_credit_limit      | double        | YES  |     | 0          |       |
| g_deposited         | double        | YES  |     | 0          |       |
| g_active            | varchar(5)    | YES  |     | True       |       |
| g_call_type         | varchar(1024) | YES  |     | Normal     |       |
| g_description       | varchar(1024) | YES  |     | NULL       |       |
+---------------------+---------------+------+-----+------------+-------+

Are there any other columns in other tables the types of which must be changed?

Thanks again for your help!
Artem.

On Sat, Oct 31, 2009 at 1:09 AM, Scott Jackson
<scottmo at adaptivecomputing.com> wrote:
> Artem,
>
> Here is the cause of the problem. The allocation balance is too large for
> the container.
>
> 2009-10-27 15:34:36.725 DEBUG Gold::Database::select  SQL Query: SELECT
> g_id,g_account,g_amount,g_credit_limit,g_start_time,g_end_time FROM
> g_allocation WHERE ( g_call_type='Normal' AND g_start_time<='1256654076' AND
> g_end_time>'1256654076' AND g_account='61' ) AND g_deleted!='True'
>
> 2009-10-27 15:34:36.725 DEBUG Gold::Database::select  SQL Results:
> 60|61|-1.06249e+08|0|0|2147483647
>
> Do you see how the allocation amount is being represented? -1.06249e+08
>
> Your number here is very large and it is not being represented in the
> database field with enough precision.
>
> Please let me know what type of database you are using. See if you can
> change the data type to have a higher precision. In my installation of
> postgres, my Allocation Amount field shows up as double precision.
>
> [scottmo at keko chargeoffbyone]$ psql gold
> Welcome to psql 8.1.6, the PostgreSQL interactive terminal.
>
> Type:  \copyright for distribution terms
>      \h for help with SQL commands
>      \? for help with psql commands
>      \g or terminate with semicolon to execute query
>      \q to quit
>
> gold=# \d g_allocation
>                            Table "public.g_allocation"
>      Column        |          Type           |              Modifiers
>
> ---------------------+-------------------------+-------------------------------------
> g_creation_time     | integer                 | not null
> g_modification_time | integer                 | not null
> g_deleted           | character varying(5)    | default 'False'::character
> varying
> g_request_id        | integer                 | not null
> g_transaction_id    | integer                 | not null
> g_id                | integer                 |
> g_account           | integer                 |
> g_start_time        | integer                 | default 0
> g_end_time          | integer                 | default 2147483647
> g_amount            | double precision        |
> g_credit_limit      | double precision        | default 0
> g_deposited         | double precision        | default 0
> g_active            | character varying(5)    | default 'True'::character
> varying
> g_call_type         | character varying(1024) | default 'Normal'::character
> varying
> g_description       | character varying(1024) |
>
> According to the online postgresql docs, "The double precision type
> typically has a range of around 1E-307 to 1E+308 with a precision of at
> least 15 digits." which should be enough precision for the ranges you are
> dealing with.
>
> The line we use to bootstrap this (in current versions of gold) is:  CREATE
> TABLE g_allocation (
>   g_creation_time integer NOT NULL,
>   g_modification_time integer NOT NULL,
>   g_deleted character varying(5) DEFAULT 'False',
>   g_request_id integer NOT NULL,
>   g_transaction_id integer NOT NULL,
>   g_id integer,
>   g_account integer,
>   g_start_time integer DEFAULT 0,
>   g_end_time integer DEFAULT 2147483647,
>   g_amount double precision,
>   g_credit_limit double precision DEFAULT 0,
>   g_deposited double precision DEFAULT 0,
>   g_active character varying(5) DEFAULT 'True',
>   g_call_type character varying(@VARCHAR_SIZE@) DEFAULT 'Normal',
>   g_description character varying(@VARCHAR_SIZE@)
> );
>
> I am assuming you are using a different database (maybe sqlite?) that may
> have smaller precisions for double precision. I assume you can figure out
> how to increase the precision of that field for your database.
>
> Thanks,
>
> Scott
>
>
> Artem Harutyunyan wrote:
>>
>> Hi Scott,
>>
>> Did you find any incosistency or problem indication in the log? Shall
>> I send you any more information?
>>
>> Cheers,
>> Artem.
>>
>> On Tue, Oct 27, 2009 at 10:21 PM, Artem Harutyunyan
>> <Artem.Harutyunyan at cern.ch> wrote:
>>
>>>
>>> Hi Scott,
>>>
>>>
>>>>
>>>> Please scp your goldd.log* to guest at adaptivecomputing.com: (password
>>>> hello)
>>>>
>>>
>>> Sorry, but the username/password does not seem to work for me. I have
>>> uploaded the log files to http://cern.ch/hartem/goldd.log.tar.gz .
>>> Could you please get the files from there?
>>>
>>>
>>>>
>>>> and indicate the problematic job charge in a follow-up email.
>>>>
>>>
>>> The job ID is 37048517 (other charge parameters can be seen from
>>> gcharge command in my previous email). The log entry for this
>>> particular charge appears to be in file goldd.log.1
>>> (Gold::Message::receiveChunk for the command is on the line 87615).
>>>
>>> If you need any more input, please let me know.
>>>
>>> Thanks for your help!
>>> Artem.
>>>
>>>
>>>>
>>>> Thanks,
>>>>
>>>> Scott
>>>>
>>>> Artem Harutyunyan wrote:
>>>>
>>>>>
>>>>> Dear Colleagues,
>>>>>
>>>>> Please consider the following commands:
>>>>>
>>>>> hartem at alien-banking:~$ glsaccount  |grep alidaq
>>>>> 61 special_account_alidaq   -106248744 ANY      NONE,alidaq
>>>>>  ANY
>>>>> hartem at alien-banking:~$
>>>>>
>>>>> hartem at alien-banking:~$ gcharge -J 37048517 -p ALICE -u alidaq -m CERN
>>>>> -P 1 -N 1 -t 1815 -d  Charging 1815 credits for the job 37048517
>>>>> executed on CERN Successfully charged job 37048517 for 1815 credits
>>>>> hartem at alien-banking:~$
>>>>>
>>>>> hartem at alien-banking:~$ glsaccount  |grep alidaq
>>>>> 61 special_account_alidaq   -106250560 ANY      NONE,alidaq
>>>>>  ANY
>>>>> hartem at alien-banking:~$
>>>>>
>>>>> Before issuing the charge command alidaq user's balance was
>>>>> -106248744, after charging 1815 credits the balance became -106250560,
>>>>>
>>>>> however -106248744 -1805=-106250559.
>>>>>
>>>>> So ghcarge has charged an extra credit. This bug(?) appears from time
>>>>> to time. Sometimes the command charges several (not necessarily 1)
>>>>> credits more, sometimes several credits less, and in some cases it
>>>>> works as expected.
>>>>>
>>>>> I am using gold version 2.1.4.2.
>>>>>
>>>>> Do you have any idea how this can be fixed?
>>>>>
>>>>> Thanks in advance for your help,
>>>>> Artem.
>>>>> _______________________________________________
>>>>> gold-users mailing list
>>>>> gold-users at supercluster.org
>>>>> http://www.supercluster.org/mailman/listinfo/gold-users
>>>>>
>>>>>
>>>>
>>>>
>
>


More information about the gold-users mailing list