January 2009 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: LargeMessage & Failover Update

by clebert.suconic＠jboss.com

"Tim Fox" wrote : | For non large messages, delivery to the client only occurs when the replication response has come back from the server. If you just do it the same as that, then should be ok? No... This is how I used to do it, and it took me a while to figure why it was not working. For non large messages, you're sure you will finish the delivery of the message when the replication response has come back. However for largeMessages it doesn't work this way. As you could interrupt chunk-delivery of the largeMessage waiting for more credits, if eventually ServerConsumer::handle is called with another message it should reject the handle being considered busy. Doing the LargeMessageDeliver only after the response is back would cause several issues on the flowControl of the delivery. "Tim Fox" wrote : | Sorry, didn't understand that explanation. This has to do with my previous explanation. When getting the credit replicated on BackupNode, it will eventually resume delivering the LargeMessage, if it ran out of credit before. That resume has also to be done synchronously or else the results are unpredictable. We would eventually get another message on handle while still delivering the first message. "Tim Fox" wrote : | What is ClientRemoteConsumer? I meant to say RemotingConnectionImpl. But more specifically, the PacketHandler on the client. On largeMessageContinuations, flowControl is being called inside the handlePacket method, and failover will dead lock if it fails while the credit is being sent to the server. Using an executor on flowControl on messageContinuations fixed the problem. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201838#4201838 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201838

17 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Generated JNI header files in SVN

by clebert.suconic＠jboss.com

I don't mind... and I have removed it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201825#4201825 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201825

17 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Fix for ClusterViewUpdateTest

by gaohoward

I updated the configures (ping period and ping timeout) to be equivalent to previous values. So test relying on related timing will not be affected by those values. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201815#4201815 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201815

17 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: First look at jBPM4 Alpha1

by kukeltje

Thomas, Good review. I tend to agree with most of what you write although I've only downloaded it yesterday, so I did not try much yet. I definately agree on the namespace thing ;-) and regarding terminology, I tend to agree as well but with some small remarks. BPMN terminology is not always 1-1 mappable on jBPM terminology, or e.g. a drop-in replacement. Therefor I think it should be introduced slowly and since it will not be 100% BPMN, there will be discrepancies. The join/fork comment I agree with (although it takes getting used to, so initially we should mention the 'old' term i n braces as wel), regarding the events etc, lets introduce them slowly and see where it leads us. On thing I think differently about though anonymous wrote : I would recommend not to mix task and gateway (just yet). Let the user draw a task with a single outgoing flow followed by a gateway. A condensed notation can always be added later when the individual components reached enough stability (i.e. after CR) I think that not doing this would result in a lot of misunderstanding with the current users. They are so accustomed to having this that if we have the intention to support this condensing, we should do it now. It should be a little more explained then I agree what the behaviour is. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201809#4201809 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201809

17 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - First look at jBPM4 Alpha1

by thomas.diesler＠jboss.com

First of all, congratulation for getting out the long awaited release - well done. I got the download from SF, installed the GPD, read the docs, had a look at the API and generally tried a few things - here my impressions. May it be helpful ;-) The new graphical designer (GPD) looks really nice. It finally adopts the BPMN standard for its graphical elements, which looks really nice. There is the notion of start event, and end event, a few gateway types and a significant number of tasks. What is a little bit confusing is some inconsistency in the terminology that is being used in the GPD, the docs and the API. BPMN talks about exclusive, inclusive, parallel and complex gateways. These have a specific semantics and everybody who knows BPMN would also know their semantics. GPD on the other hand talks about exclusive, fork, join The jbpm4 docs sais anonymous wrote : | (BPMN note: when we mention activities here, we are not only refering to BPMN activities, but also to BPMN events and BPMN gateways.) | If possible, I would not do that. An activity is an activity (namely a task or a sub-process), an event is an event, a gateway is a gateway. jBPM4 allows multiple outgoing flows on a task. This combines the notion of task with the notion of gateway. It is however not clear what type of gateway is being combined here and if we assume that it is an exclusive gateway, it not clear whether the full functional set of an exclusive gateway is also available on the task. Can every task have multiple outgoing flows? I would recommend not to mix task and gateway (just yet). Let the user draw a task with a single outgoing flow followed by a gateway. A condensed notation can always be added later when the individual components reached enough stability (i.e. after CR) The docs talk about "end state" - this should be "end event" - cancel and error are "event details" that if attached to an end event are called "result" Generally, I'd recommend not to invent new terminology for a concept in the BPMN editor that already has a "standard" name in BPMN. Also don't use existing BPMN terminology to mean something different. The API combines the notion of ProcessInstance with that of Token in a single interface and calls it "Execution". This will not allow these two concepts to evolve independently for example when you want to add state independently to the ProcessInstance and the Token. It is generally better to model a concept like ProcessInstance as such and call it by it's name. If you cant do much (yet) with a ProcessInstance you will have a short method list, which is ok. The GPD elements in the process definition should be defined in their own namespace Instead of | <start g="32,22,80,40"> | jBPM should have | <start gpd:g="32,22,80,40"> | This allows GPD metadata to evolve independently of the process definition itself and also makes it clear that 'g' is a presentational and not a functional element. During GPD installation, the license text is missing. This sounds like a lot of criticism, but my general impression is good. The docs cover sufficiently what is there already. Designer and implementation seem to be in sync. The list of examples covers available functionality. Thanks for Alpha1, I'm looking forward to stuff to come. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201795#4201795 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201795

17 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MutableClassInfo?

by kabir.khan＠jboss.com

"adrian(a)jboss.org" wrote : | SUMMARY | | Besides completing the generics stuff in the javassist class info | so we can use it, the TypeInfo needs additional "optional" interfaces for mutable | behaviour. | Cool, that is exactly what I had in mind when originally talking to Ales about this. "adrian(a)jboss.org" wrote : | But the real work is making aop/classinfo properly | integrate with the classloading structure. | This is WIP, in AOP I am reimplementing the classpools http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201653#4201653 I have hacked around the missing features that will be introduced by JBCL-78 for now, once jboss-cl 2.0.2 is released I'm good. I am more or less done with this, but need to add logging and to test this out in AS. For ClassInfo, the underlying ClassPool that is used by XXXInfo will need to be the same as the ClassPool that is used by AOP, so some centralized repository of ClassPools will probably be needed. For AOP this is done by https://svn.jboss.org/repos/jbossas/projects/aop/trunk/aop/src/main/java/..., but maybe this should be moved into jboss-reflect? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201793#4201793 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201793

17 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Plague of temp VFS files and OOM on redeploy

by alesj

"alesj" wrote : "scott.stark(a)jboss.org" wrote : | | The old MainDeployer has an explicit delete of existing content in the tmp directory when it was updated | | | OK, I'll check how we used to do this in old MD. | We did this in DeploymentInfo::cleanup, which was called in MD's undeploy --> destroy. Should we have something similar in our DeployersImpl? | unregisterMBean(context); | removeClassLoader(context); | cleanup(context); <-- HERE | Currently at HERE we only do metadata cleanup. AbstractDeploymentContext: | public void cleanup() | { | cleanupRepository(this); | } | Perhaps adding something like this in AbstractVFSDeploymentContext | @Override | public void cleanup() | { | super.cleanup(); | root.close(); // or adding new VirtualFile::cleanup() method? | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201791#4201791 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201791

17 years, 2 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Per window customization even when it is not dashboard

by vivek_saini07

pls somebody can tell me more elegant solution. The point is I am not allowed to change source code of JBP. Solution should be pluggable. I can only change XMLs like jboss-service.xml. Can I handle this by making new MBean. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201788#4201788 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201788

17 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MutableClassInfo?

by kabir.khan＠jboss.com

"adrian(a)jboss.org" wrote : | Nope/Yup. The Scoped classpools are wrong. They don't understand the classloading | The new classpools I am working on will View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201784#4201784 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201784

17 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MutableClassInfo?

by stale.pedersen＠jboss.org

"adrian(a)jboss.org" wrote : | This just lets you create a ClassInfo from the bytecode. | But for this to work properly it needs to have a understanding as to which | classloader the class/bytecode should be assigned. | yes, well yes and no. when creating a CtClass object yes, when creating a ClassFile object then no. as mentioned ClassFile is a impl detail, but we need the functionality it brings. - but if we can implement what we currently need from ClassFile to *ClassInfo* then no. eg, atm we can:ClassFile cf = new ClassFile( new DataInputStream(new FileInputStream(file))); "adrian(a)jboss.org" wrote : | "stale.pedersen(a)jboss.org" wrote : | | - do finegrained operations/checks ala annotation visibility (which is only possible with javassist and not java.lang.reflect afaik) | | | | Not sure why you need this. I assume you mean being able to look | at annotations that are not Runtime visible? Is that really a good idea? | we use it a lot in aop so yes, we need it. "adrian(a)jboss.org" wrote : | Unless you mean being able to get the resulting byte code from the manipulation | so you can defineClass() on it I don't think it is a good idea. | | Allowing access to implementation details is not a good idea, | e.g. the deprecated TypeInfo.getClass() should not be there. | | Instead we need to extend the abstraction to make this unnecessary. | This could include some helper methods to defineClass() from a ClassInfo. | i was not thinking of getting the .class. i was thinking of something like CtClass.getClassFile() since atm that is the only way we can get info like annotation visibility, but if we can implement to get that from TypeInfo/etc its not needed. for now we havent added any methods to add/change methods/fields/etc to ClassInfo, we just changed the factory to not use the .class representation when creating the ClassInfo object to use the CtClass instead. - which i guess it was meant to anyway if im understanding adrian correct. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4201779#4201779 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4201779

17 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums January 2009