Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (athena.apache.org: domain of ryan@betterservers.com
 designates 199.58.199.50 as permitted sender)
From: Ryan Dietrich <ryan@betterservers.com>
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_8721FE43-E765-406A-9BAE-197EC1FF00D7"
Message-Id: <4348F690-4630-4EBB-9634-1888B27CB07C@betterservers.com>
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
Subject: Async Job / Event Bus issue
Date: Tue, 2 Jul 2013 14:17:43 -0600
References: <CDF37BFC.4292C%murali.reddy@citrix.com>
 <AEC9F4C4-60A7-4C08-A8C9-A855A467368A@betterservers.com>
To: dev@cloudstack.apache.org
In-Reply-To: <AEC9F4C4-60A7-4C08-A8C9-A855A467368A@betterservers.com>

--Apple-Mail=_8721FE43-E765-406A-9BAE-197EC1FF00D7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

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=3DEnumType.STRING)
    @Column(name=3D"instance_type", length=3D64)
    private Type instanceType;
   =20
    @Column(name=3D"instance_id", length=3D64)
    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.
>=20
> https://reviews.apache.org/r/12223/
>=20
> Things that still need to be thought through:
>=20
> 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)
>=20
> 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.
>=20
> -Ryan Dietrich


--Apple-Mail=_8721FE43-E765-406A-9BAE-197EC1FF00D7--