[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