cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Dietrich <>
Subject Async Job / Event Bus issue
Date Tue, 02 Jul 2013 20:17:43 GMT
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 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.

    @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.


On Jul 2, 2013, at 8:15 AM, Ryan Dietrich <> wrote:

> Patch submitted.
> 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 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message