airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marlon Pierce <marpi...@iu.edu>
Subject Re: Error saving job details after remote submission
Date Mon, 26 May 2014 14:33:28 GMT
By "do this now", I mean isolate the .sql definition files in the
registry code base, even if running in the same JVM as the API server.

Marlon

On 5/26/14 10:32 AM, Marlon Pierce wrote:
> So when we eventually separate the Registry as a separate Thrift
> service, we can isolate the .sql definition files from the API server. 
> Is there a way to do this now?
>
> Marlon
>
> On 5/26/14 10:28 AM, Chathuri Wimalasena wrote:
>> Yes. They run in the same VM.
>>
>>
>> On Mon, May 26, 2014 at 10:24 AM, Marlon Pierce <marpierc@iu.edu> wrote:
>>
>>> My bad, thanks for the clarification.  The API server and the Registry
>>> run in the same VM?
>>>
>>> Marlon
>>>
>>> On 5/26/14 10:07 AM, Chathuri Wimalasena wrote:
>>>> Hi Shabaz,
>>>>
>>>> Registry is initiated when airavata server starts. That's why sql files
>>> are
>>>> at airavata-api/airavata-api-server/src/main/resources. If you want to
>>>> change the database, you want to edit those script files. If it is a
>>> change
>>>> in table names or columns, you need to change associate openJPA model
>>>> classes too.
>>>>
>>>> Thanks..
>>>> Chathuri
>>>>
>>>>
>>>> On Mon, May 26, 2014 at 8:59 AM, Marlon Pierce <marpierc@iu.edu> wrote:
>>>>
>>>>> The versions in
>>>>> airavata/modules/registry/airavata-jpa-registry/src/main/resources/
>>>>> should be the ones that are used to set up the databases.  Can you check
>>>>> the DB itself to see if the settings were changed?
>>>>>
>>>>> Someone else will have to explain why the .sql files are also in the
API
>>>>> server directory
>>>>> (./airavata-api/airavata-api-server/src/main/resources/) but I suspect
>>>>> it is related to our dependency on OpenJPA calls in the current version
>>>>> of the Registry CPI.
>>>>>
>>>>> Marlon
>>>>>
>>>>> On 5/26/14 8:28 AM, Shahbaz Memon wrote:
>>>>>> Now I have tried to increase the "varchar" capacity of the job_id
>>>>> attribute
>>>>>> to 1000, but still not able to avoid the truncation error.
>>>>>>
>>>>>> Here is the trace,
>>>>>>
>>>>>> http://www.heypasteit.com/clip/1E0D
>>>>>>
>>>>>> By the way when I dissect the server distribution I see that there
are
>>>>>> registry-derby.sql  and registry-mysql.sql files in the
>>>>>> <apache-airavata-server-path>/bin/database-scripts/, and two
files with
>>>>> the
>>>>>> same name can also be found inside the
>>>>>> airavata-jpa-registry-0.12-SNAPSHOT.jar. I am not sure which one
is
>>>>> loaded
>>>>>> during the run time, although I have changed both, but still see
no
>>>>> impact
>>>>>> on the mysterious database creation phase that is exporting
>>>>> <table>.job_id
>>>>>> attribute with 255 chars.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Shahbaz
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, May 26, 2014 at 9:26 AM, Shahbaz Memon <m.memon@fz-juelich.de
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Marlon,
>>>>>>>
>>>>>>> Thanks for your reply. In unicore, jobs possess a complex
>>> ws-addressing
>>>>>>> endpoint reference type structure which will be for sure exceeding
the
>>>>>>> limit of 255 chars.
>>>>>>>
>>>>>>>> If you changed the definition of JOB_DETAIL here to use more
>>>>> characters,
>>>>>>> would this solve your problem?
>>>>>>>
>>>>>>> I was not able to apply the changes. I will try it this week
and see
>>> how
>>>>>>> it works.
>>>>>>>
>>>>>>> Thanks and best regards,
>>>>>>>
>>>>>>> Shahbaz
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, May 23, 2014 at 4:40 PM, Marlon Pierce <marpierc@iu.edu>
>>> wrote:
>>>>>>>> Hi Shahbaz, did my workaround suggestion work for you?
>>>  Fundamentally,
>>>>>>>> though, we need to make the size limit on the jobId explicit
to the
>>>>>>>> plugin developer, or else come up with a solution that doesn't
>>> require
>>>>>>>> modifying the field size in the DB schema, since we can't
assume in
>>> all
>>>>>>>> cases that plugin developers have access to the registry
config file.
>>>>>>>>
>>>>>>>>
>>>>>>>> Marlon
>>>>>>>>
>>>>>>>> On 5/16/14 10:22 AM, Shahbaz Memon wrote:
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> At the BES provider side when I am try to save submitted
job details
>>>>>>>> through GFacUtils.saveJobStatus(jobExecutionContext,details,
>>>>>>>> JobState.SUBMITTED);
>>>>>>>>> The provider throws an exception, the whole trace can
be accessed
>>>>> under,
>>>>>>>>> http://www.heypasteit.com/clip/1DFF
>>>>>>>>>
>>>>>>>>> May be the database model is limiting the provider instance
to
>>> insert
>>>>>>>> complete job reference.
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Shahbaz
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>> ------------------------------------------------------------------------------------------------
>>> ------------------------------------------------------------------------------------------------
>>>>>>>>> Forschungszentrum Juelich GmbH
>>>>>>>>> 52425 Juelich
>>>>>>>>> Sitz der Gesellschaft: Juelich
>>>>>>>>> Eingetragen im Handelsregister des Amtsgerichts Dueren
Nr. HR B 3498
>>>>>>>>> Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen
Huthmacher
>>>>>>>>> Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
>>>>>>>>> Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing.
Harald Bolt,
>>>>>>>>> Prof. Dr. Sebastian M. Schmidt
>>>>>>>>>
>>> ------------------------------------------------------------------------------------------------
>>> ------------------------------------------------------------------------------------------------
>>>


Mime
View raw message