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

[Design the new POJO MicroContainer] - Re: Accessing content of vfsfile url fails

by scott.stark＠jboss.org

I assume the embedded stuff does. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4100890#4100890 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4100890

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Support .. notion in vfs paths

by scott.stark＠jboss.org

It points to the current file. These should be equivalent: vf.findChild("."); vf.findChild(""); and these: vf.findChild("x"); vf.findChild("./x"); View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4100889#4100889 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4100889

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Support .. notion in vfs paths

by alesj

Regarding http://jira.jboss.com/jira/browse/JBMICROCONT-211 Is there some similar VFS use case for a single '.' in the path? What exactly does a '.' do? Pointing to current directory? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4100885#4100885 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4100885

17 years, 1 month

1
0
0 / 0

[Design of JBossCache] - Re: Reusing options in PojoCache

by bstansberry＠jboss.com

FYI, Manik's going to have to respin 1.4.1.SP6 due to JBCACHE-1209, so you might want to get the change in the respin. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4100873#4100873 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4100873

17 years, 1 month

1
0
0 / 0

[Design of JBossCache] - Re: Reusing options in PojoCache

by jason.greene＠jboss.com

Thanks for the heads up. I checked and 2.0 doesn't make this mistake. I will take a look at patching the 1.4 branch. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4100864#4100864 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4100864

17 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: New wireformat and client side remoting

by timfox

More thoughts, how this might look: abstract class Packet { long correlationID; } //Example class CreateConnectionMessage extends Packet { //all the params in here } interface Dispatcher { Handler registerHandler(int handlerID); void sendOneWay(Packet packet, int handlerID); void sendBlocking(Packet packet, int handlerID); } interface Handler { void handle(Message message); } Then you have one instance of the Dispatcher on the client side (clientDispatcher), and you have another instance of the Dispatcher on the server side (serverDispatcher) (Remember, it's symmetrical) Here are some examples of usage: 1) Send a non persistent message to a queue on the server a) Create a SendMessage message b) Call sendOneWay on the clientDispatcher c) Sometime later on the server side the serverDispatcher receives the message and calls handle() on the Handler instance that was registered on the server side to handle message sends 2) Send a persistent message to a queue on the server same a) b) c) as above but the d) server invokes sendOneWay() on the serverDispatcher with a message instance representing the response with the corelation id set. e) clientDispatcher receives the message and looks up correlation id in its internal map, unblocks thread with result. 3) Send a message from server to consumer on client a) [The consumer will already have registered a handler with the client Dispatcher] b) Server invokes sendOneWay() on the serverDispatcher with the message instance. c) The clientDispatcher receives the mesage, looks up the appropriate handler and invokes handle() on it. d) Notice that there is no need for the clientDispatcher to have specific knowledge of the session and consumer objects - all it needs to know about are handlers! Nice and simple huh? 4) Non blocking reliable send of message (this is over and above JMS) a) client invokes sendOneWay()on clientDispatcher with a message b) client carries on doing something else c) server receives message looks up handler and invokes handle() on it. d) server persists message and calls sendOneWay() on the serverDispatcher e) server carries on doing something else f) client receives message on calls handle() on response handler. g) Now client knows that messages was persisted, but since non blocking can get much better throughput not limited by network RTT View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4100857#4100857 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4100857

17 years, 1 month

1
0
0 / 0

[Design of JBossCache] - Reusing options in PojoCache

by bstansberry＠jboss.com

Jason, Just got bit by a bad practice, and I see PojoCache is doing the same thing (at least in 1.4.1.x), so wanted to give you a heads up. The bad practice is trying to reuse an Option -- i.e. create and configure an Option, cache a ref to that instance and then pass that instance to the cache whenever you make an invocation w/ that semantic. PojoCache does this in InternalDelegate with the gravitateOption_ and skipLockOption_ fields. This is a problem because JBC makes no guarantees that it won't change the internal state of an Option during the course of an invocation. Manik and I had a discussion about this a couple weeks back, but I can't find it to give you a link. JBCACHE-1209 is an example of a subtle issue where JBC was changing the internal state of an option the AS code was trying to reuse. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4100856#4100856 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4100856

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Accessing content of vfsfile url fails

by alesj

Is any of the Bill's VFS 'Handler extends URLStreamHandler' classes used anywhere? If yes, where and how? btw: urlCache usage in VirtualFileURLConnection looks suspicious :-) ... I would expect some weak usage View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4100852#4100852 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4100852

17 years, 1 month

1
0
0 / 0

[Design of JBossXB] - Re: Seeing IAssemblyDescriptorMetaData error again?

by scott.stark＠jboss.org

Ok, I'm switching jbossas to an mc snapshot until the beta6 release is out. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4100849#4100849 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4100849

17 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - New wireformat and client side remoting

by timfox

To kick off the discussion, here are my initial comments on Jeff's wiki: In the diagram where you map MINA objects to JMS objects, we should remember that the JMS layer is a thin layer on the front. MINA needs to map to a JMS agnostic layer (which may look a bit like JMS). I'm thinking like the following: | JMS Agnostic MINA | --- -------- ---- | | IoConnector IoAcceptor | \ / | \ IoSession/ | Connection----Connection------------------ | | | | | | | Session Session | / \ \ | Producer Consumer Consumer | I think Connection Session and Consumer are good abstractions for generic messaging But Producer and Browser only live on the JMS side. Producing messages and browsing can be methods on the agnostic Session class. IOSession will only need to maintain a map of references to the agnostic objects not the JMS objects. It will need to maintain such a map so the objects can be called back. So.. what we end up with is basically similar to the current Dispatcher but on the client side. In effect the system is *symettrical*. We have a dispatcher on the client side which looks up objects in order to deliver responses, and we have dispatcher on the server side which looks up objects to deliver requests. Really requests and responses are the same thing, it's just the direction of travel is different. I think this symetry is aesthetically pleasing which is often a good sign. Regarding the messages: Perhaps it is not such a good idea to classify the messages as synchronous or asychronous since some messages can be sent either asynchronously or synchronously - a good example is sending a message -for persistent messages they are sent synchronously, for non persistently, but the message being sent is the same. We should come up with a set of messages (which can be either requests or responses) and the api determines whether they are sent asynchonrous or not. e.g. interface OurRemotingAPI() { void sendOneWay(...); void sendBlocking(...);' Handler registerCallbackHandler(..); } Actually, currently the *only* messages we send asynchronously are: 1) consumer change rate 2) messages send (for non persistent messages) All the rest are synchronous. We could consider making the following asynchronous: 1) Cancel delivery 2) Start/stop connection In terms of how to correlate requests and responses to give synchronous calls, it should be fairly simple to do something like the following: 1) Send message with "request id" in message. 2) Block thread and put in map with key of request id. 3) When response comes back, look at request id. 4) Lookup thread in map with that request id and wake it up. Some kind of wait/notify should do the trick. Another thing to think about is management messages. You probably want to define a message type as a management message (or a set of management messsages). The idea here is the user could send a messages saying "createQueue" or "getNumberOfMeessafesInQueue" or any number of different operations that we currently do via JMX, and get results that way without JMX. Finally one other thing to think about is how MINA is going to support SSL and HTTP. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4100845#4100845 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4100845

17 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2007