[Design of JBoss ESB] - Re: Supporting entry-point
by beve
As an example of entry point usage (from the Drools Fusion User Guide):
rule "apply fee on withdraws on branches"
| when
| WithdrawRequest( $ai : accountId, processed == true ) from entry-point "Branch Stream"
| CheckingAccount( accountId == $ai )
| then
| // apply a $2 fee on the account
| end
Instead of inserting events directly into the working memory, you insert them into the entry point as shown in the following example:
// create your rulebase and your session as usual
| StatefulKnowledgeSession session = ...
|
| // get a reference to the entry point
| WorkingMemoryEntryPoint atmStream = session.getWorkingMemoryEntryPoint( "ATM Stream" );
|
| // and start inserting your facts into the entry point
| atmStream.insert( aWithdrawRequest );
By requesting the WorkingMemoryEntryPoint from the session we are able to insert our facts into it and this will be separate from the "default" working memory.
In the ESB will want to give users the ability to use entry points in thier rules. To do this we need to let them specify which objects(facts) should be inserted in to the separate entry-points. Currently all are inserted in the the working memory (which I understand is simply a WorkingMemoryEntryPoint named "DEFAULT").
Burr suggested that the following configuration option to be added:
<object-path esb="body.TheOrderHeader" entry-point="OrderStream" />
And this would result in something like this in the ESB code base:
WorkingMemoryEntryPoint atmStream = session.getWorkingMemoryEntryPoint( "OrderStream" );
| atmStream.insert(orderHeader);
|
Burr also mentioned that we should support the ability to set the startTimeStamp on an event:
anonymous wrote : The date time stamp should be based on message DOB but perhaps overrideable here as well
Every event in Drools has an associated timestamp assigned which by default is read from Session Clock.
This startTimeStamp is assigned to the event at the time the event is inserted into the working memory.
But you are given the opportunity to have Drools use a different timestamp, for instance the DOB of the ESB Message object, by specifying that the timestamp of the fact being should be used instead:
@timestamp( <attributeName> )
So if we specified dob as the attribute name, the object being inserted is expected to have a field named dob, and that that field contains the timestamp that will be used when creating the EventFactHandle.
Just how this is going to look I don't know at the moment and I'd need to look into this and try it out.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4239933#4239933
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4239933
15 years, 6 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Journal Cleanup and Journal Compactor (Repost)
by clebert.suconic@jboss.com
Since now I don't need the transaction summary any more (just number of records associated with the transaction at the currentFile), I will be able to move pending transactions. And for doing that I will need to keep all the transaction IDs and everything else.
For doing that, I will need to use temporary files, and rename them as you suggested.
- I will open a journal file with a temporary name. (Open here, means gets it from the cached files, or create a new one).
- As I read the journal files I add the valid records to the temporary file. (I will off course open new files as I fill the file).
- Add a temporary small file when I start renaming the files, and deleting the old files. and delete that file when I'm done.
The only issue I have now is allowing concurrent appends to the journal, as I'm compacting the files.
The problem is, when deleteing or updating a record, I don't know where the AddRecord is going to be located at. So, I don't know where to add the negative value to.
So, what I'm thinking as a solution is:
- During compacting, all Adds, updates and deletes are stored to the current-file, as we aways do.
- But instead of discounting POSFiles right away, I cache those IDs on a collection. When I'm done compacting I do a fast operation applying the reference counts accordingly.
- Case the server is interrupted during reload, the delete or update will take the original location of the record.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4239872#4239872
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4239872
15 years, 6 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Journal Cleanup and Journal Compactor
by clebert.suconic@jboss.com
Since now I don't need the transaction summary any more (just number of records associated with the transaction at the currentFile),
I will need to use temporary files, and rename them as you suggested.
- I will open a journal file with a temporary name. (Open here, means gets it from the cached files, or create a new one).
- As I read the journal files I add the valid records to the temporary file. (I will off course open new files as I fill the file).
- Add a temporary small file when I start renaming the files, and deleting the old files. and delete that file when I'm done.
The only issue I have now is allowing concurrent appends to the journal, as I'm compacting the files.
The problem is, when deleteing or updating a record, I don't know where the AddRecord is going to be located at. So, I don't know where to add the negative value to.
So, what I'm thinking as a solution is:
- During compacting, all Adds, updates and deletes are stored to the current-file, as we aways do.
- But instead of discounting POSFiles right away, I cache those IDs on a collection. When I'm done compacting I do a fast operation applying the reference counts accordingly.
- Case the server is interrupted during reload, the delete or update will take the original location of the record.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4239872#4239872
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4239872
15 years, 6 months