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

[Design of JBoss/Tomcat Integration] - Re: Separating properties on the tomcat deployer

by bstansberry＠jboss.com

When Anil and I were discussing this a month ago, I was thinking in terms of separating out a separate deployer bean from TomcatDeployer, with that bean exposing properties for all the default clustering values. It's task is to inject the defaults in JBossWebMetaData. Well, umm, that just seems silly. :-) Shouldn't we have something like a jbossweb.deployer/conf/jboss-web.xml file where we declare all the defaults? WebAppParsingDeployer would handle that file in much the same way JBossEjb2ParsingDeployer handles standardjboss,xml. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102344#4102344 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102344

18 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Initial cut of MC integration work

by timfox

Just looking at Andy's recent commit. Looks good. :) A few initial comments/questions from a cursory look at the code: 1) The Bridge MBean is still there 2) Are DestinationMBean/TopicMBean/QueueMBean used any more? (If not we should remove them) 3) Do we really need ManagedDestination, ManagedQueue and ManagedTopic? ManagedTopic is only meaningful to JMS (the new core eventually won't know about topics - since this is a JMS concept). 4) As you mention, probably Configuration attributes should not be static. 4) Configuration: So far we have separate config files for a) serverpeer (also contains old post office config) b) connection factories c) destinations d) persistence manager? can we/should we combine these further? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102339#4102339 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102339

18 years, 5 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Connection with JBossPortal from a remote host

by thomas.heute＠jboss.com

Wrong forum it has nothing to do with JBoss Portal design. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102338#4102338 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102338

18 years, 5 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: remoting streams

by david.lloyd＠jboss.com

"jahlborn" wrote : the choice made in the remoting impls leads to some performance consequences. every remote retrieval operation for inputstream requires two remote calls (hasNext and next). additionally, for the collection based impls (IteratorObjectSource), every object retrieval requires two remote calls! Ah, but the secret here is that you don't make a network round-trip for each method call. Every time an item or a batch of items is sent, an indicator can easily be added to signify that there are more items (or not). This is because each stream handler has its own wire implementation. So it's actually more efficient than RPC-style invocations (in the spirit of Remoting 3 in general, which seeks to move away from the RPC style). Not only does this mean that you don't make the extra remote request for "hasNext", but you can actually have higher throughput overall since the stream handler can forward multiple objects at one time rather than making a round trip for each one. "jahlborn" wrote : the other big thing that stuck out to me is the lack of any idempotent guarantees. it's possible this is provided by the underlying framework, but, if not, it's a significant weakness. Yes, the idea is that reliability is provided by the framework, and the user need not worry about it. If a request fails irreparably, a RemotingException is thrown. "jahlborn" wrote : another problem that's more related to remoting as a whole (at least in previous remoting versions), is the lack of an interface similar to java.rmi.server.Unreferenced. this becomes more important for things like streams which can be holding system resources which are relatively scarce (open file handles, database connections, etc). it's not uncommon for a client to die unexpectedly before the "close" method is invoked on the server. this will leave the stream resource open indefinitely. This is up to the individual stream handlers, however for the default stream handlers the close() method will be called when the remote side either (a) closes the stream explicitly or (b) lets it die unreferenced while still open. It is possible that there is a use case to handle these situations differently, but so far I know of no such case. "jahlborn" wrote : one last minor point is that i see no support for duplicate close calls (again, this could be managed elsewhere by the underlying framework). Every usage of close() uses the java.io.Closeable interface, which specifies that "If the stream is already closed then invoking this method has no effect". I do intend to keep those semantics. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102333#4102333 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102333

18 years, 5 months

1
0
0 / 0

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

by timfox

"jmesnil" wrote : "timfox" wrote : More thoughts, how this might look: | | | | abstract class Packet | | { | | long correlationID; | | } | | | | interface Dispatcher | | { | | Handler registerHandler(int handlerID); | | | | void sendOneWay(Packet packet, int handlerID); | | | | void sendBlocking(Packet packet, int handlerID); | | } | | | | interface Handler | | { | | void handle(Message message); | | } | | | | I have a simple prototype which is quite similar: | | | | interface Packet | | { | | long correlationID; | | String handlerID; | | } | | | | class CreateSessionRequest extends Packet { | | } | | class CreateSessionResponse extends Packet { | | } | | | | interface Client | | { | | Handler registerHandler(int handlerID, Handler handler); | | void unregisterHandler(int handlerID); | | | | void sendOneWay(Packet packet); | | | | Packet sendBlocking(Packet packet); | | } | | | | interface Handler | | { | | void handle(Packet packet); | | } | | | Sounds pretty much right to me :) You could probably just use the current Dispatcher and change it to implement the new Dispatcher interface. You could also re-use the current requests and reponses (of course some won't be appropriate any more) - these are the packets. You would need to change the serverInvoker method of course to instead call back into the Dispatcher, so the Dispatcher can notify the correct handlers. A couple more things to think about: 1) How does the user configure the new transport? The user needs to be able to choose from: a) socket b) ssl c) http each will have its own set of parameters some config is appropriate for the server side and some for the client. e.g. thread pool sizes and MINA threading model. 2) We need some kind of "heartbeat" functionality. I.e. periodically sending ping messages on the connection, so the server knows if the client is still alive, and the client knows if the connection is still alive. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102327#4102327 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102327

18 years, 5 months

1
0
0 / 0

[Design of JBoss internal QA (Test Suite)] - Re: Testsuite issues with multicast routing (JBAS-4939)

by akostadinov

I think we have no more test suite issue. I'll comment on JIRA tomorrow, once the test suite run is completed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102326#4102326 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102326

18 years, 5 months

1
0
0 / 0

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

by timfox

"trustin" wrote : | MINA already has support for SSL including StartTLS. It's known to be very reliable. SSL is provided as a filter so just inserting a new SSL filter will enable SSL immediately. No sweat. | | MINA recently imported AsyncWeb source code into its sandbox, and it should be included into the official distribution after some polishing. MINA has an infra for implementing protocol codec and AsyncWeb provides HTTP codec on top of it. Therefore, you can build your own lightest-weight web server very easily. Please take a look at this example: | | Please feel free to contact me or the MINA team whenever you need some support related with MINA including questions like 'does feature XXX supported in MINA?' Actually we got most, and want to add as much as possible harmonizing all the features with each other. Sounds good. Thanks Trustin View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102325#4102325 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102325

18 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Failing FileVFSUnitTestCase.testVFSFileURIFactory in VFS

by alesj

"alesj" wrote : "scott.stark(a)jboss.org" wrote : What delete fails? I can't see how the testFileExists delete should fail. | If you run this test case on Winz, the file is not deleted, so File.delete (tmp.delete()) doesn't return true. | Since, similar to URLExistsUnitTestCase, looks like something is again holding the resources. | 3500 DEBUG [FileVFSUnitTestCase] ==== Starting testFileExists ==== | 3500 INFO [FileVFSUnitTestCase] +++ testFileExists, tmp=C:\tmp\vfs\vfs33660.root\testFileExists33661.tmp | 3500 DEBUG [FileVFSUnitTestCase] testFileExists took 0ms | 3500 DEBUG [FileVFSUnitTestCase] ==== Stopping testFileExists ==== | | junit.framework.AssertionFailedError: tmp.delete() | at org.jboss.test.virtual.test.FileVFSUnitTestCase.testFileExists(FileVFSUnitTestCase.java:1287) | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40) | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90) | | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102324#4102324 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102324

18 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Failing FileVFSUnitTestCase.testVFSFileURIFactory in VFS

by alesj

"scott.stark(a)jboss.org" wrote : What delete fails? I can't see how the testFileExists delete should fail. If you run this test case on Winz, the file is not deleted, so File.delete (tmp.delete()) doesn't return true. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102313#4102313 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102313

18 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Issues with EJB2 ClusterConfigMetaData

by bstansberry＠jboss.com

JIRA is http://jira.jboss.com/jira/browse/JBAS-4947 . Trivial bit about the property name is checked in. Please let me know next time you update the snapshot in the repository; once that change is in I'll add default load balance policy elements to standardjboss.xml. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102312#4102312 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102312

18 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 November 2007