October 2006 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Remoting - Client Asynchronous Calls

by ovidiu.feodorov＠jboss.com

genman wrote : | "2. Synchronous raw send" - In general, I find APIs that use byte[] sort of cumbersome. Its brother "send(byte [], int off, int len)" is better, but still ugly. I would avoid that sort of thing. Using actual objects is better. I mean, if you really want to optimize things, have your objects implement Externalizable. I don't see how "instanceof" and a cast would be slow. We most likely won't have any send(byte[]), but an sent(ByteBuffer) or equivalent instead. There's a vigorous discussion on this subject going on here: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=92869 The point in contention is whether to offer this as a top level API call, or make it accessible via a "chained marshaller" mechanism Tom Elrod is experimenting with as we speak. We're supposed to have a conference to discuss this, some time mid week. If interested, I can send you the call info. genman wrote : | "4. asynchSend" - I can't see how this is different than "invokeOneWay" I guess you say that, but still suggest adding it? I like symmetry. However, adding a new method name doesn't make too much sense if the current one provides the behavior we need, so I guess I won't make too much noise over that. The document is just a proposal, it's not etched in stone :). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980253#3980253 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980253

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Remoting - Client Asynchronous Calls

by genman

Having reviewed what you wrote and the remoting API, I don't quite understand why additional methods are necessary. "2. Synchronous raw send" - In general, I find APIs that use byte[] sort of cumbersome. Its brother "send(byte [], int off, int len)" is better, but still ugly. I would avoid that sort of thing. Using actual objects is better. I mean, if you really want to optimize things, have your objects implement Externalizable. I don't see how "instanceof" and a cast would be slow. "4. asynchSend" - I can't see how this is different than "invokeOneWay" I guess you say that, but still suggest adding it? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980249#3980249 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980249

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Client failover redeliveries discussion

by ovidiu.feodorov＠jboss.com

I also noticed that you don't deal with QueueBrowsers, only producers and consumers. This is perhaps a minor oversight, right? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980243#3980243 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980243

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Client failover redeliveries discussion

by ovidiu.feodorov＠jboss.com

I've checked in a simple failover test that fails. It's too late to look too deep into it now, but I'll get back tomorrow. In the mean time, you could take a look. It's ManualClusteringTest.testSimpleFailover() View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980242#3980242 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980242

19 years, 5 months

1
0
0 / 0

[Design of JBoss ESB] - Table object_snap uses Oracle keyword UID

by jeffdelong

I downloaded jboss-esb-4.0.4B1MP1, and wanted to use Oracle for the tables. In the process of converting the HSQL script I found that the object_snap table uses UID as a column name, which is an Oracle keyword (hence the script blew up). CREATE TABLE object_snap (uid number(19,0) NOT NULL View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980239#3980239 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980239

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Messaging and Remoting

by ovidiu.feodorov＠jboss.com

Tim wrote : | This doesn't make any sense to me. | NIO and streams don't work well together. | Where exactly did you see the word "stream" in the Remoting API extension document? Tim wrote : | ovidiu.feodorov(a)jboss.com wrote : | | Not necessarily, the Remoting implementation can create ByteBuffers by wrapping the byte[] we send as an argument without copying anything, but I don't see any problem with using ByteBuffer instead of byte[] in the method signature. | | | | I don't think wrapping the buffer around a byte[] works with direct byte buffers. | The memory allocated when creating a direct buffer is outside of the JVM heap. The allocation is done through native methods, and it's likely to be significantly more expensive than creating non-direct buffers. I am not saying that we shouldn't use ByteBuffers for the low-level access API, I am saying that we should be very careful how we handle them, and what kind of buffers we pass around, so the drawbacks don't outweigh the speed advantages obtained by having I/O devices writing directly in the memory areas managed by direct buffers. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980227#3980227 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980227

19 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: status of merge, non persisted script on fork, and n-out

by kukeltje

would it be to difficult to persist the script on a fork. Since http://jira.jboss.com/jira/browse/JBPM-308 is deferred to 3.2 (according to the log there) can we decide now? What is the alternative? imo it is a nice pattern that can be easily configurable with either a script or an action that calls a JBoss Rules file... Ronald View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980223#3980223 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980223

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Messaging and Remoting

by clebert.suconic＠jboss.com

Tim, Ovidiu.... replace my suggestion from Input/OUtpuSTream to ByteBuffer. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980218#3980218 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980218

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Messaging and Remoting

by ovidiu.feodorov＠jboss.com

Tim wrote : I'm also getting worried that we've spent a long time on this, and it seems not everyone yet understands the basic differences between a blocking and non blocking approach, this is not a good sign :( Can you be a little bit more explicit on that? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980213#3980213 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980213

19 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: status of merge, non persisted script on fork, and n-out

by kukeltje

The script on the fork is not persisted, but it is not mentioned anywhere that it should be. What I did find out is that there is a lot of difference between the docs, schema (which in itself is very inconsistent) and behaviour/api of the core. I would like to make a suggestion to get this in line before 4.0 or even better 3.3. Shall I file a jira issue for this? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980209#3980209 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980209

19 years, 5 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 October 2006