cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Huang <Alex.Hu...@citrix.com>
Subject RE: Async Job / Event Bus issue
Date Tue, 02 Jul 2013 20:27:27 GMT
Ryan,

There's explicit code to remove those two columns.  IIRC, the reason is because asyncjob actually
uses those two fields to sequence jobs on the same id and type.  So when the job is done,
then it removes those two fields so it doesn't block the next job.

--Alex

> -----Original Message-----
> From: Ryan Dietrich [mailto:ryan@betterservers.com]
> Sent: Tuesday, July 2, 2013 1:18 PM
> To: dev@cloudstack.apache.org
> Subject: Async Job / Event Bus issue
> 
> I've found a bug that I am having trouble determining the cause.  Basically,
> my instance_type and instance_id columns are showing up when the job is
> submitted, but they do not show up when the job is completed or updated.
> When I look in the database, those columns are null, however, they are
> published correctly to the event bus on submit.
> 
> I went a step further and verified that SqlGenerator.java is actually using
> these columns on insertion and for querying the fields back out.
> 
> INSERT INTO async_job (async_job.user_id, async_job.account_id,
> async_job.session_key, async_job.job_cmd, async_job.job_cmd_originator,
> async_job.job_cmd_ver, async_job.job_cmd_info, async_job.callback_type,
> async_job.callback_address, async_job.job_status,
> async_job.job_process_status, async_job.job_re sult_code,
> async_job.job_result, async_job.instance_type, async_job.instance_id,
> async_job.job_init_msid, async_job.job_complete_msid, async_job.created,
> async_job.last_updated, async_job.last_polled, async_job.uuid) VALUES
> (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
> 
> I also verified that the column has a database @Column annotation.
> SqlGenerator appears to be using reflection to determine the "attributes"
> that get mapped into columns.
> 
> (from AsyncJobVO.java)
>     @Enumerated(value=EnumType.STRING)
>     @Column(name="instance_type", length=64)
>     private Type instanceType;
> 
>     @Column(name="instance_id", length=64)
>     private Long instanceId;
> 
> What could be causing the instance_id and instance_type to drop on the
> floor?  I am literally logging the job right after it says it has been written to the
> database, I log it again right after it is retrieved from the dao via findById.
> Either the dao isn't populating the volumes when it queries the AsyncJobVO
> back out (and subsequently updates the columns with null values), or it's
> something that I'm simply not seeing.
> 
> Help?
> 
> On Jul 2, 2013, at 8:15 AM, Ryan Dietrich <ryan@betterservers.com> wrote:
> 
> > Patch submitted.
> >
> > https://reviews.apache.org/r/12223/
> >
> > Things that still need to be thought through:
> >
> > 1. Should the async command event type be a column on async job (and be
> an attribute of AsyncJobVO)?
> > 2. Should getInstanceId and getInstanceType of AsyncCmd be abstract
> > instead of implemented with null values? (would require updating every
> > async command in the system, and would break everyones async plugin
> > commands)
> >
> > Oh, and after figuring out how the parameter annotation works (and
> ApiDispatcher uses reflection to iterate over parameters, ugh), I saw
> BaseCmd.java has a HashMap<String, String> of the arguments passed in
> from the user.
> > I went with the APIDBUtils query function for UUID's because I saw no
> precedent for accessing that HashMap after initial argument handling.
> >
> > -Ryan Dietrich


Mime
View raw message