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