[Design of JBoss jBPM] - Re: Analytical and operational dashboards
by KrisVerlaenen
At this point, I believe the database itself could almost be considered an API, it defines the data that could be reasoned on. Currently there is need to put a Java API on top of that, as it will become very difficult to create one that is both generic enough to support all use cases and specific enough to offer simple methods to end users. I do believe though that it could be useful to define a "minimal" schema (the minimal data that the db should contain to make it useful), and think about making that extensible so people can add more information later (and be able to use that extra information somehow in the analysis).
Are there any plans to support business indicators (KPIs)? Because people usually don't really reason about "the number of process instances", more about "outstanding orders", "the time to complete an order", etc. This might be somewhat related to CEP: creating higher-level business events from lower-level process events. Just a thought for the future though, to support business users. Simple operational dashboards for admins are probably the first step towards that.
Heiko: I'd love to hear about your ideas / technology / progress on this next week, you don't be surprised if I ask you that question ;)
Kris
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184984#4184984
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184984
15 years, 11 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Status of LargeMessages work
by clebert.suconic@jboss.com
This is the status of my current work on MessageChunk and LargeMessages.
It is committed on https://svn.jboss.org/repos/messaging/branches/Branch_Chunk_CRS2/ waiting revision before we add it to trunk. Branch_Chunk_CRS2 was just created today (r5188)
I - I have added a method getPacketSize on the Packet interface. The abstract class is still returning (at this point at least) the DefaultPacketSize, but MessageSend, Chunk and Receive are calculating the packetSize accordingly.
With that the InVM transport will also work for big messages, and we can avoid extra unecessary buffer creations.
* As soon as we merge it on trunk, we could have all the packets implementing this. But this is not a really high priority.
II - I have added a new interface called ServerLargeMessage which will be implemented by each storage-manager we have. We have JournalServerLargeMessageImpl and NullStorageManager. The StorageManager will be responsible for the instantiation of this class.
III - I have separated the reference counting of references and durable references on Messages (that fix on paging discussed on this thread: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=144128)
As soon as we remove the reference from the queue (ACKs) I decrement the refCount. I use that ref to delete large messages stored on files.
IV - Paging could page largeMessages also. (On that case I don't take the bodySize in consideration, as that will be stored outside of the memory).
V - The ChunkSize is configured on the ConnectionFactory, and the default is 100k
VI - I have created a new Packet caleld SessionSendChunkMessage, and it is being used both ways (client2server and server2client).
VII - When uploading files, I'm using an extension as ".tmp" until they completed. I have found a few edge cases on keeping track of those files after a restart, and I need to have some discussion about how to do it. It looks like I will need to inspect the files for files on journal and paging when we restart.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184980#4184980
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4184980
15 years, 11 months