Ryan, Those fields were added to indicate the instances (volumes, vms, etc) having pending/active async jobs. The customers' main use case was - by instance id, find out the jobs that are currently being executed for this instance. Once the job is completed, the field is offset to NULL.
-Alena. On 7/2/13 1:17 PM, "Ryan Dietrich" <r...@betterservers.com> wrote: >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 > >
