July 2008 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Integrating Netty into JBM2

by trustin

Even further, I think we can reuse DataInput and DataOutput interface instead of MessagingBuffer. The reasoning behind this is that putInt() is the only random access method in MessagingBuffer and it's only used for writing the length field during encoding. Except that, every access is sequential. What the current decoder implementation does is to read the length field first and wait until the whole message is received, which means the whole message is read into memory. Therefore, using a stream to read a message will never block once a message is properly split (or assembled) in the networking layer (MINA or Netty level). Writing a message is a different matter because we need to fill the length field. We could fill the length field in the networking layer (MINA or Netty level) to work around this issue. The disadvantage of this approach is that each networking layer implementation should know how one or more packets are split or assembled into a message. It means both MINA-based transport and Netty-based transport should know where the length field of a message is located. It's a little bit of code duplication, but I don't think this will change once implemented because their change means the protocol incompatibility. read and write methods for SimpleString could be provided as static utility methods or member methods of SimpleString. WDYT? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161749#4161749 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161749

17 years, 5 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: GA release of Profiler 2

by jesper.pedersen

GA in somewhat in the future -- we are going to release Beta2 very soon. The more feedback and help we get the sooner the GA will appear. We are currently in need of JSF/RichFaces resources if you are interested in that ;) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161726#4161726 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161726

17 years, 5 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: Installed profiler today... Now what?

by jesper.pedersen

You need to use the client in order to interact with the profiler. There are various command that it supports like startProfiler and stopProfiler. See the README.txt file for details and examples. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161725#4161725 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161725

17 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Defining a public API for jBPM

by pete.muir＠jboss.org

Thomas, Seam consumes the jbpm API, and it would be great if you could include the methods we use as part of the stable API you are developing. http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/bpm and http://fisheye.jboss.org/browse/Seam/trunk/src/main/org/jboss/seam/pageflow is our integration code - ping me if you want to discuss this further offline. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161722#4161722 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161722

17 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Integrating Netty into JBM2

by trustin

Hi, I've been trying to integrate Netty into JBM2 since the end of last week. I enountered a problem while implementing MessagingBuffer. According to the source code, a MessagingBuffer implementation is supposed to increase its capacity automatically when it runs out of space. It's what exactly MINA IoBuffer does. Netty has a CompositeByteArray which does similar thing, but it's different from IoBuffer in that it doesn't have position and limit, which means there's no need for flip or rewind. Also, automatic expansion of the buffer is implemented very differently - it's not reallocation and copy but adding a new chunk to the end of the list. There are a few ways to resolve this differences (in the order of better performance): 1) Replace MINA stuff with Netty and remove position(), limit(), flip(), rewind() and etc from MessagingBuffer. 2) Emulate the current behavior with NIO BuyeBuffer classes. 3) Emulate the current behavior with Netty classes Of course, the option 1 involves the biggest change among the three and will require the changes in unit tests, while it would be fun for me. Another alternative is the option 2 - most part of the code is done in NIO ByteBuffer so the implementation shouldn't be that difficult, but I still have to deal with auto-expansion, which leads to unnecessary memory copy. Option 3 is the worst of all because we are going to build something on top of something built on top of existing buffer (or byte array). Which option shall I go with? Whichever option we choose, we should make all the existing tests pass. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161721#4161721 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161721

17 years, 5 months

1
0
0 / 0

[Design of JBoss Profiler] - GA release of Profiler 2

by arnold.maderthaner

Hi ! When will you bring the GA release (final release) of profiler 2 ? yours Arnold View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161709#4161709 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161709

17 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jBPM3 should release lock-step with jPDL4

by thomas.diesler＠jboss.com

I aligned the even alpha releases with jBPM3. Another important point (apart from inter-project dependencies) is management of the workload for the whole team. For any given eight week period you have N projects to work on and you can schedule your workload such that everything gets done by a well defined date. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161706#4161706 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161706

17 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Need for database compatibility between jBPM versions

by tom.baeyens＠jboss.com

"thomas.diesler(a)jboss.com" wrote : This is based on my understanding that a process definition is an immutable entity, which is defined in XML. | process definitions can be considered as immutable, correct. "thomas.diesler(a)jboss.com" wrote : | The state of running processes is persisted in the database. For many a reason It cannot be expected that jBPM can be updated for running proccess. there are two types of migration 1) migrating a process instance to a new process definition in the same jBPM installation 2) migrating the complete jBPM database to a new major version (3.x to 4) In the general case, process instance migration is too complex, as you don't know to what extend the new process definition will look like the old one. However, in the majority of use cases, the updates to the process are fairly limited. If we provide a process instance migration that takes into account an optional node-name-mapping, then I think we have covered the 80% of the migrations with 20% of the effort. Migrating the runtime state is doable IMO. The logs and history is always too complex. What I think we definitely should consider is process instance migration from 3.x to 4. Our users *will* have to do this. With our without our help. This is the feedback that we got at jBPM community day. I think that should be definitely feasible with serialization to XML. After the clean shutdown, we should be able to provide a tool that serializes a the complete process instance information to XML and load that XML file in the new DB. IMO, this is mostly a question of resources. "thomas.diesler(a)jboss.com" wrote : If this feature is required we need to see this reflected in the test suite. In other words, as long as there are no automated tests that verify that an update of jBPM from version X to version Y for a non trivial set of running processes - this feature is not there. agreed. "thomas.diesler(a)jboss.com" wrote : | | ProcessEngine.prepareForShutdown() | | | | This will allow processes to terminate, while others cannot start. A user is expected to setup a new instance of jBPM version Y that can receive new process requests. i don't think this is realistic for the complete process instances. think of the legal case taking 3 years to complete and new legislation requiring updates to the process in the meantime. we need some form of process instance migration for that. but a clean shutdown could make sure that all asynchronous messages get processed before the shutdown is completed. that only leaves the timers to be taken into consideration. "thomas.diesler(a)jboss.com" wrote : IFrom that perspective, it is unnecessary and not even desired to provide backwards compatibility for database layout. i agree. backwards compatibility of DB layout is not feasible and not necessary. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161705#4161705 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161705

17 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Integrating aop.xml information into metadata view

by wolfc

Add to this mix the ejb3 metadata bridge which extends mdr with a facility to implement the logic of resolving the right metadata to an annotation. So you end up with a BridgedMetaDataLoader which has multiple MetaDataBridges. The actual implementations of MetaDataBridges are within the specific components, so for example ejb3-interceptors has all the knowledge of interpreting annotations and metadata. That's how I would like to keep: the functional component dictates that logic. Right now the connection between an AOP domain and the EJB is coded in Ejb3Deployment. So on an EJB container (which delegates to a ManagedObjectAdvisor) has the full view of all annotations. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161701#4161701 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161701

17 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Defining a public API for jBPM

by thomas.diesler＠jboss.com

Please discuss here Need for database compatibility between jBPM versions http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161691#4161691 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161692#4161692 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161692

17 years, 5 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums July 2008