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

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

by timfox

To clarify what I was saying. If we were to augment the remoting API to add methods that take ByteBuffers[] (or byte[] or whatever) for both receiving and sending, then in the non blocking case we would have to cope with partial sends and receives in the application. We could of course build intelligence into the API to cope with the partial sends /receives - but this is pretty much the raison d'etre for NIO frameworks such as MINA AFAIK. So we'd be re-inventing the wheel. If we didn't build that intelligence into the API, then we would have to handle it ourselves in the application layer, which again would be re-inventing the wheel, this time in the application. If we agree that we don't want to build our own NIO framework then, I suggest we should just use one that we know works already. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980363#3980363 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980363

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - VirtualFile.toURL() returning vfsfile:

by bill.burke＠jboss.com

Make a bunch of changes on my box so that VirtualFile.toURL() returns a vfsfile: based URL. The Handler's toURL()/getURL() will return the real URL (if possible) of the file, while VF returns the vfsfile: based one. One huge problem I've run into is that vfsfile: based urls seem to REALLY slow down URL classloaders. Looking into the problem now. It may be that I have to cache VFs based on URL. Don't know yet. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980359#3980359 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980359

19 years, 5 months

1
0
0 / 0

[Design of JBoss Portal] - JBOS portal + hibernate

by vipinmpd08

Hi I am new to JBOSS Portal concept and also hibernate technology JBOSS Portal has built in package for that? Please do replay And also send useful links Thanks Vipindas View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980324#3980324 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980324

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: POJOization of config elements

by manik.surtani＠jboss.com

Re: #1, as Scott suggested, you shouldn't need a PropertyEditor for Enums with the MC. And Re: #3: anonymous wrote : | | | 3) Eviction configuration naming. The Pojo configuration looks like this: | | class EvictionConfig -- top level object. Configure your default eviction policy here, plus the interval for the eviction thread. Also takes a list of... | | class EvictionRegionConfig -- one per region. Configure the Fqn here, plus the class name of the EvictionPolicy (if you want to override the overall default). Also takes an impl of.... | | interface EvictionConfiguration. the type-specific config for the EvictionPolicy. | | Couple problems here. First "EvictionConfiguration" would be better named "EvictionPolicyConfig", since its a config for a specific policy. But, that interface already exists in 1.4, so changing that name will break any existing custom impls. Don't know if we care about that. Second, there's already an unused interface named EvictionPolicyConfig, along with a DefaultEvictionPolicyConfig impl. That code is unused; looks like it was meant more as a top-level config object. We should drop that code after ensuring that any design ideas from it get picked up in the new stuff. | | | Yes, this stuff needs a bit of cleaning up. I suggest: 1) Leave EvictionConfiguration as it is. 2) EvictionPolicyConfig extends EvictionConfiguration, and internally we use EvictionPolicyConfig. We also document EvictionPolicyConfig and suggest that people use this, giving us a migration path. 3) Clean up on the unused code around here. 4) Remove the now redundant EvictionPolicyClass attribute - as this is now set as a part of a Region. What do you think? I don't mind removing EvictionConfiguration altogether and breaking 1.4.0 compat as we're doing this in other areas anyway, but we aren't changing that much in the eviction policies so I'm not sure about this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980308#3980308 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980308

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: POJOization of config elements

by manik.surtani＠jboss.com

To add perspective, the above comment was in response to point #2 that you mentioned. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980305#3980305 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980305

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: POJOization of config elements

by manik.surtani＠jboss.com

anonymous wrote : | | One temptation is to break compatibility with existing config files for BR by swapping the property names. There aren't likely to be many existing configs that have BR. E.g. | | Not true. This is for JBC2.0.0/AS5. BR is available in AS 4.0.5, and I suspect people will start using it. anonymous wrote : | | | public Element getBuddyReplicationConfiguration() | | public void setBuddyReplicationConfiguration(Element config) | | | | public BuddyReplicationConfig getBuddyReplicationConfig() | | public void setBuddyReplicationConfig(BuddyReplicationConfig config) | | | Ugh! :-) I'd steer well clear of such ambiguities, if I were you! If we can use a PropertyEditor where needed, I'd prefer this approach. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980304#3980304 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980304

19 years, 5 months

1
0
0 / 0

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

by timfox

"clebert.suconic(a)jboss.com" wrote : | | As far as I looked into the code, Postoffice will only accept one binding using a single name. We will be loading a Durable subscription from a dead node, where the current node could have the same subscription already existent (that's why I decided to transfer contents) | Another reason why you can't transfer the contents is that it could very very slow. There may be 10s of millions of messages in the partial queue. It shouldn't be too hard to extend the clustered post office to allow more than one local clustered queue on a cluster router instance. anonymous wrote : | | but now I realize there might be a problem: | | What if another client is already subscribed to an existent queue. Can we have two clients with the same connectionID/subscriptionName? Do you mean client id? Why would this be a problem? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980278#3980278 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980278

19 years, 5 months

1
0
0 / 0

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

by timfox

Personally - if you're going to provide an API that supports non blocking operations without limiting what the user can do in terms of power/performance then what's wrong with the Channel/Selector API? This was designed by experts to do just that. Why do we think we can do any better? If we're trying to provide a higher level abstraction to the the channel/selector API then we're going down the route of writing our own NIO framework, which seems a big waste of time to me since there are already frameworks out there who have gone through that pain. (Not Invented Here syndrome etc) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980275#3980275 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980275

19 years, 5 months

1
0
0 / 0

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

by timfox

Another thing to bear in mind with the proposed API. If you have a method write(byte[] byte), then when used with a non blocking implementation this method might return after having written only a partial number of the bytes. A similar reasoning applies to reads too. This is what non blocking is all about. A blocking implementation would block until all the bytes had been written. This preventing the thread neing used for anything else while the blocking is occurring. This means the semantics of the API differ depending on whether the actual implementation is blocking or non blocking. This also means it's going to be up to the application to piece together requests and responses. This is where most of the difficulty in a non blocking approach comes in. Trying to get the same API to cope with both approaches strikes me as somewhat analagous to the medieval alchemists trying to turn lead into gold. It seems to me that our biggest issue is getting an implementation up and running. So far we haven't even got the interface sorted. At the end of the day our end user won't give two hoots what our internal API looks like, but they will care that our performance sucks. As I've said before, I could probably knock something up in MINA in a few weeks. Considering we only have just over 4 weeks to have this fully implemented, I think this is our only feasible option. After that, we philosophise as much as we want about how to retrofit that in remoting. But please please let's not try and write a new non blocking framework - let's not go down the "Not invented here" path. There are already tried and tested frameworks out there. Let's get something working, and think about how this nicely fits into a new remoting api later when we have the luxury of time. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980273#3980273 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980273

19 years, 5 months

1
0
0 / 0

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

by timfox

"ovidiu.feodorov(a)jboss.com" wrote : | Where exactly did you see the word "stream" in the Remoting API extension document? | Why are you presuming I was referring to your posts? I was answering one of Clebert's posts where he *did* propose using streams. ovidiu.feodorov(a)jboss.com wrote : | 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. | Are suggesting we preclude people from using direct byte buffers? As far as I am concerned it is up to the user to use the API properly. We shouldn't prevent them doing high performance stuff because we thing they're a bit stupid and might make mistakes. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980269#3980269 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3980269

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