version 1.1.2.2, 2013/06/03 22:34:01
|
version 1.1.2.8, 2013/09/14 23:08:12
|
|
|
| |
STATUS | STATUS |
| |
<<< This section is being maintained during the review and checkin process |
<<< The TODO section is being maintained during the review and checkin process |
to keep track of problems, errors, notes, etc. Must be deleted before | to keep track of problems, errors, notes, etc. Must be deleted before |
checkin to head of tree. Please feel free to add notes, etc in this | checkin to head of tree. Please feel free to add notes, etc in this |
section as you review/test.>>>>>> | section as you review/test.>>>>>> |
| |
|
NOTES On working with task branch. |
|
|
|
Merge out Process |
|
|
|
To keep our TASK branch in sync with the current head of tree we need |
|
to do a regular merge out. the TaskMakefile contains the makefile |
|
procedures to do this efficiently. NOTE: Following these procedures is |
|
important in that you are merging out new material each time you do |
|
the merge out. If you were just to repeatedly merge out, you would be |
|
merging previously merged changes a second time causing a real mess. |
|
|
|
Start with new directory and put TaskMakefile above pegasus (needed so you |
|
have this file for the initial operations. |
|
|
|
make -f TaskMakefile branch_merge_out BNAME=PEP317-pullop ## takes a long time |
|
|
|
This checks out current head, merges it into task branch and sets tags |
|
for the mergeout. Note that at the end of this step this work is |
|
part of the TASK... branch. |
|
|
|
NOW check for conflicts, errors, etc. that resulted from the merge. |
|
Look for conflict flags, compare the results (I use linux merge as a |
|
good graphic compare tool) and build and test. When you are satisfied |
|
that the merge out is clean, you can commit the results to the TASK... |
|
branch |
|
|
|
To commit the work to this into Task branch |
|
|
|
make -f mak/TaskMakefile branch_merge_out_commit BNAME=PEP317-pullop |
|
|
|
or manually commit and finish as follows |
|
|
|
cvs commit |
|
make -f mak/TaskMakefile branch_merge_out_finish BNAME=PEP317-pullop |
|
|
|
## This last step is important since it cleans up temporary tags to prepare |
|
you for the next checkout |
|
|
|
COMPARE TASKBRANCH WITH HEAD |
|
|
|
In a new pegasus work space do same as above for merge out. |
|
|
|
make -f TaskMakefile BNAME=PEP317-pullop |
|
|
|
This produces a result which is all of the head merged into the branch. |
|
A diff of this is all the new changes to the head of tree that you will |
|
include into the merge. |
|
|
|
|
|
TODO list: |
|
1. Binary operation from OOP. Need to add counter to binary |
|
protocol to be able to count objects in response. Generates |
|
warnings in things like messageserializer and does not work with |
|
OOP right now. |
|
2. OpenExecQuery - Code is incorrect in that it used InstancesWithPath |
|
where the spec is instances with no path. Need new function to wrap |
|
getInstanceElement(withoutPathElement) in XmlReader. Note that |
|
Alternate is to put flag on InstancesWith Path to say no path |
|
3. Code for Pull part of OpenQueryInstancesRequest a) should be part of |
|
the common CIMOperationRequestDispatcher execCommon code. |
|
4. The changes to WQLCIMOperationRequestDispatcher and CQL... for handling |
|
pull not completed so we feed the responses back to the EnmerationContext |
|
queues |
|
3. Lots of minor TODOs, diagnostics, etc. |
|
4. External runtime variables. Decide this as part of PEP. The variables |
|
exist in CIMOperationRequestDispatcher but not in CIMConfig. The primary |
|
ones to consider are: |
|
a. System maxObjectCount. Setting some maximum size on what a pull |
|
client can request (i.e. the maximum size of the maxObjectCount on |
|
Open... and pull operations. |
|
b. Pull interoperationTimeout (max times between operations). This is |
|
the maximum number of seconds on the operationTimeout parameter of the |
|
Open operations |
|
c. Maximum size of the responseCache before it starts backing up |
|
responses to the providers. |
|
5. Decision on EnumerationContext timeout (separate thread or just |
|
checks during other operations). Can we, in fact really keep the |
|
enumeration context table and queue under control without monitoring |
|
with a separate thread. We must monitor for: |
|
a. Client operation that stop requesting (i.e. inter operation time |
|
exceeds operationTimeout). Note that if it simply exceeds the time |
|
the next operation does the cleanup. The issue is those clients that |
|
simply stop and do not either close or go to completion. |
|
b. We should protect against providers that no not every finish delivering |
|
or take to long between deliveries. This does not exist in Pegasus |
|
today |
|
6. Clean up code in Dispatcher. Want to at least reduce the code for the |
|
Open Operations to a set of templates so we know that the code is the |
|
same for all operations. Right now the existing operations enum, assoc, |
|
etc. are all in templates but not the open operations. Note that the |
|
pull is a single template for both pullInstances and pullInstancePaths. |
|
However, we might be able to reduce this to a single function by adding |
|
a new level to CIMMessage.h (CommonPullResponse) |
|
7. Extension to avoid double move of objects in CIMResponseData (one |
|
into enumerationContext queue and second to new cimResponseData for |
|
response. Want to avoid second move by extending Open/Pull response |
|
messages to include count and CIMResponse data to count objects out |
|
of queue when converting (avoids the second move). Big issue here |
|
with binary data since need to extend format to count it. |
|
8. NEXT TASKS: |
|
a. get the pull operations rather than a template into a single |
|
function by creating a new CIMPullResponse message in CIMMessage.h that |
|
contains the pull data. Then we can use a single function to process all |
|
pull operations. |
|
b. test the timeout thread |
|
c. New Mergout to bring up to to date again. |
|
d. Fix known problem with the interop provider. |
|
|
|
14 September 2013 CVS update |
|
Merged out up to 25 August. Cleaned up all operations and standardized code. |
|
At this point the non pull operations code is in a set of templates but the |
|
pull is not yet. |
|
Fixed a significant number of problems so that it appears that the operations |
|
except for OpenExecQuery run stably, at least with the pullop test program. |
|
Note that there is a problem in that the Interop control provider is not |
|
returning its singleton wbemserver object for some reason. Causes a test |
|
failure |
|
|
|
Fixed for 16 June CVS Update |
|
1. Cleaned up the enumerationContext and Table release functions and tested |
|
to confirm that we do not lose memory in either normal sequences or |
|
sequences that close early. Cleaned up pullop and added more tests |
|
Taged Before: PREAUG25UPDATE and after POSTAUG25UPDATE |
|
|
|
Fixed for 9 June CVS update |
|
1. Cleaned up code for OpenQueryInstances. Note that this is incomplete. |
|
No support in WQL or CQL Operations |
|
2. |
|
|
|
What was fixed for 5 June checkin. |
|
1. Extended ResponseTest MOF for for both CMPI and C++ subclasses |
|
2. Fixed issues with pullop. |
|
3. Fixed temp issue with CIMResponseData size by putting in mutex. That |
|
is not a permanent fix but it gets around issue probably in the control |
|
of the move logic that meant counts were off. |
|
4. Fixed issues in Dispatcher so that associator code works. Still messy |
|
code in the dispatcher. |
|
5. Changed name of Enumerationtable.h & cpp to EnumerationContextTable.* |
|
6 Changed name of ResponseStressTest module, classes, etc. |
|
|
|
TAG: TASK_PEP317_5JUNE_2013_2 |
|
|
2 June 2013 | 2 June 2013 |
| |
Issues - KS | Issues - KS |