[Design of JBoss jBPM] - Re: MessageService and JMS
by mteira
anonymous wrote : first of all a remark. i understand your frustrations. we are finishing a big restructuring of the jbpm source code base. also the build scripts still have quite some rough edges. please bear with us. it's normal that you experience some problems in the new structure. let us know your problems. we are eager to get it right asap.
|
Thanks for the response. I was starting to think that all my trouble was my fault, and didn't want to disturb you anymore with my problems. I understand the problems on such a restructuring, and would like to help finding them.
anonymous wrote : about the /jbpm web-uri: i suppose that this change was necessary to get the designer working with the web console, right ? the default proposed deployment url is now /jbpm. jbpm-console.war fits better with our new naming scheme. also i like the /jbpm-console URI better then /jbpm. so we'll update the default that is presented in the deployment tab in the eclipse designer. would that resolve your second issue.
In its original state, that application.xml failed to deploy inside my JBoss (4.0.4 GA). Don't remember the exact reason but complained about the war entry. That was the reason why I changed it specifying the web-uri. On a first attempt, I chose "jbpm-console" just to resemble the name of the webapp, but then, when I tried to deploy a process from Eclipse (using the gd from the designers-kit 3.1) it failed because it tried to use jbpm instead of jbpm-console. I didn't find a place to configure that parameter and so, I changed that web-uri to be /jbpm. I don't mind what web-uri to use, only that it should be changed in the two places (web-uri and designer process deployer).
I've updated my local copy of the repository and tried to build just using ant (I had some trouble running some of the CVS targets and messed up my install ;-) ). I'm trying now to build the designer and it worked, running ant at:
jbpm.3\designer\jpdl\org.jbpm.gd.jpdl.build
Then, I tried to install it into a fresh eclipse install. Just using the jbpm-gpd-site-3.0.11-SNAPSHOT.zip generated into the repository, telling the eclipse to update from a local archived site. The eclipse is version 3.2, installed running rule:
ant install.eclipse
into that same directory. Something bad happened, because after restarting, Eclipse is not able to open any project, and I can see into the error log:
java.lang.NullPointerException
| at org.jbpm.ui.util.JbpmClasspathContainer.getJarNames(Unknown Source)
| at org.jbpm.ui.util.JbpmClasspathContainer.createJbpmLibraryEntries(Unknown Source)
| at org.jbpm.ui.util.JbpmClasspathContainer.getClasspathEntries(Unknown Source)
| at org.eclipse.jdt.internal.core.JavaModelManager.containerPutIfInitializingWithSameEntries(JavaModelManager.java:494)
| at org.eclipse.jdt.core.JavaCore.setClasspathContainer(JavaCore.java:4118)
| at org.jbpm.ui.util.JbpmClasspathContainerInitializer.initialize(Unknown Source)
| at org.eclipse.jdt.internal.core.JavaModelManager.initializeContainer(JavaModelManager.java:1900)
| at org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer(JavaModelManager.java:1267)
| at org.eclipse.jdt.core.JavaCore.getClasspathContainer(JavaCore.java:1470)
| at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:2169)
| at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:2073)
| at org.eclipse.jdt.internal.core.JavaModelManager.determineIfOnClasspath(JavaModelManager.java:808)
| at org.eclipse.jdt.internal.core.JavaModelManager.create(JavaModelManager.java:697)
| at org.eclipse.jdt.internal.core.JavaModelManager.create(JavaModelManager.java:626)
| at org.eclipse.jdt.core.JavaCore.create(JavaCore.java:1383)
| at org.eclipse.jdt.internal.ui.ResourceAdapterFactory.getAdapter(ResourceAdapterFactory.java:44)
| at org.eclipse.core.internal.runtime.AdapterFactoryProxy.getAdapter(AdapterFactoryProxy.java:63)
| at org.eclipse.core.internal.runtime.AdapterManager.getAdapter(AdapterManager.java:256)
| at org.eclipse.core.runtime.PlatformObject.getAdapter(PlatformObject.java:66)
| at org.eclipse.jdt.internal.ui.filters.NamePatternFilter.select(NamePatternFilter.java:62)
| at org.eclipse.jdt.internal.ui.viewsupport.ProblemTreeViewer.isFiltered(ProblemTreeViewer.java:187)
| at org.eclipse.jdt.internal.ui.packageview.PackageExplorerPart$PackageExplorerProblemTreeViewer.isFiltered(PackageExplorerPart.java:301)
| at org.eclipse.jdt.internal.ui.packageview.PackageExplorerPart$PackageExplorerProblemTreeViewer.getFilteredChildren(PackageExplorerPart.java:281)
| at org.eclipse.jface.viewers.AbstractTreeViewer.getSortedChildren(AbstractTreeViewer.java:534)
| at org.eclipse.jface.viewers.AbstractTreeViewer$1.run(AbstractTreeViewer.java:719)
| at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67)
| at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren(AbstractTreeViewer.java:696)
| at org.eclipse.jface.viewers.TreeViewer.createChildren(TreeViewer.java:892)
| at org.eclipse.jface.viewers.AbstractTreeViewer.handleTreeExpand(AbstractTreeViewer.java:1240)
| at org.eclipse.jface.viewers.AbstractTreeViewer$4.treeExpanded(AbstractTreeViewer.java:1252)
| at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:181)
| at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
| at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:928)
| at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:952)
| at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:937)
| at org.eclipse.swt.widgets.Tree.wmNotifyChild(Tree.java:6254)
| at org.eclipse.swt.widgets.Control.WM_NOTIFY(Control.java:3794)
| at org.eclipse.swt.widgets.Composite.WM_NOTIFY(Composite.java:1166)
| at org.eclipse.swt.widgets.Control.windowProc(Control.java:3298)
| at org.eclipse.swt.widgets.Display.windowProc(Display.java:4025)
| at org.eclipse.swt.internal.win32.OS.CallWindowProcW(Native Method)
| at org.eclipse.swt.internal.win32.OS.CallWindowProc(OS.java:1842)
| at org.eclipse.swt.widgets.Tree.callWindowProc(Tree.java:1319)
| at org.eclipse.swt.widgets.Tree.WM_LBUTTONDOWN(Tree.java:5171)
| at org.eclipse.swt.widgets.Control.windowProc(Control.java:3279)
| at org.eclipse.swt.widgets.Tree.windowProc(Tree.java:4768)
| at org.eclipse.swt.widgets.Display.windowProc(Display.java:4025)
| at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method)
| at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:1923)
| at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2966)
| at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1914)
| at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1878)
| at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:419)
| at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
| at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:95)
| at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:78)
| at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:92)
| at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:68)
| at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400)
| at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:177)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
| at java.lang.reflect.Method.invoke(Unknown Source)
| at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336)
| at org.eclipse.core.launcher.Main.basicRun(Main.java:280)
| at org.eclipse.core.launcher.Main.run(Main.java:977)
| at org.eclipse.core.launcher.Main.main(Main.java:952)
One thing that I'm confused about is that it seems not to be a jbpm core included into the zip file, as I found into the local-site bundled with the starters-kit. This is what I have into my jbpm-gpd-site-3.0.11-SNAPSHOT.zip file:
C:\Documents and Settings\Administrador\jbpm\repository\jbpm\designer\jpdl\3.0.1
| 1-SNAPSHOT>unzip -l jbpm-gpd-site-3.0.11-SNAPSHOT.zip
| Archive: jbpm-gpd-site-3.0.11-SNAPSHOT.zip
| Length Date Time Name
| -------- ---- ---- ----
| 0 14/09/06 14:55 features/
| 0 14/09/06 14:55 plugins/
| 399 14/09/06 14:26 .project
| 8446 14/09/06 14:55 features/org.jbpm.gd.jpdl.feature.source_3.0.11.jar
| 9088 14/09/06 14:55 features/org.jbpm.gd.jpdl.feature_3.0.11.jar
| 1292277 14/09/06 14:55 plugins/org.apache.xerces_2.8.0.v200606131651.jar
| 484641 14/09/06 14:26 plugins/org.eclipse.draw2d_3.2.0.v20060626.jar
| 89698 14/09/06 14:26 plugins/org.eclipse.emf.common.ui_2.2.0.v20060627105
| 7.jar
| 154682 14/09/06 14:26 plugins/org.eclipse.emf.common_2.2.0.v200606271057.j
| ar
| 169972 14/09/06 14:26 plugins/org.eclipse.emf.ecore.xmi_2.2.0.v20060627105
| 7.jar
| 749588 14/09/06 14:26 plugins/org.eclipse.emf.ecore_2.2.0.v200606271057.ja
| r
| 125210 14/09/06 14:26 plugins/org.eclipse.emf.edit.ui_2.2.0.v200606271057.
| jar
| 225067 14/09/06 14:26 plugins/org.eclipse.emf.edit_2.2.0.v200606271057.jar
|
| 748073 14/09/06 14:26 plugins/org.eclipse.gef_3.2.0.v20060626.jar
| 91656 14/09/06 14:26 plugins/org.eclipse.jem.util_1.2.0.v20060530_RC2.jar
|
| 35071 14/09/06 14:26 plugins/org.eclipse.wst.common.core_1.1.0.v200606130
| 645.jar
| 182926 14/09/06 14:26 plugins/org.eclipse.wst.common.emf_1.1.0.v2006061306
| 45.jar
| 122035 14/09/06 14:26 plugins/org.eclipse.wst.common.emfworkbench.integrat
| ion_1.1.0.v200606130645.jar
| 37662 14/09/06 14:26 plugins/org.eclipse.wst.common.environment_1.0.100.v
| 200606130645.jar
| 123058 14/09/06 14:26 plugins/org.eclipse.wst.common.frameworks.ui_1.1.0.v
| 200606130645.jar
| 106267 14/09/06 14:26 plugins/org.eclipse.wst.common.frameworks_1.1.0.v200
| 606130645.jar
| 162102 14/09/06 14:26 plugins/org.eclipse.wst.common.project.facet.core_1.
| 1.0.v200606130645.jar
| 102255 14/09/06 14:26 plugins/org.eclipse.wst.common.ui.properties_1.0.100
| .v200606130645.jar
| 119099 14/09/06 14:26 plugins/org.eclipse.wst.common.ui_1.1.0.v20060614212
| 2.jar
| 31779 14/09/06 14:26 plugins/org.eclipse.wst.common.uriresolver_1.1.0.v20
| 0606130645.jar
| 367107 14/09/06 14:26 plugins/org.eclipse.wst.sse.core_1.1.0.v200606141450
| .jar
| 670902 14/09/06 14:26 plugins/org.eclipse.wst.sse.ui_1.0.101.v200606191900
| .jar
| 96453 14/09/06 14:26 plugins/org.eclipse.wst.validation.ui_1.1.0.v2006061
| 30645.jar
| 184914 14/09/06 14:26 plugins/org.eclipse.wst.validation_1.1.0.v2006061306
| 45.jar
| 603544 14/09/06 14:26 plugins/org.eclipse.wst.xml.core_1.1.0.v200606142000
| .jar
| 646889 14/09/06 14:26 plugins/org.eclipse.wst.xml.ui_1.0.100.v200606141450
| .jar
| 61015 14/09/06 14:26 plugins/org.eclipse.wst.xsd.core_1.1.0.v200606130645
| .jar
| 918340 14/09/06 14:26 plugins/org.eclipse.wst.xsd.ui_1.1.0.v200606142122.j
| ar
| 197009 14/09/06 14:26 plugins/org.eclipse.xsd.edit_2.2.0.v200606271057.jar
|
| 697947 14/09/06 14:26 plugins/org.eclipse.xsd_2.2.0.v200606271057.jar
| 636 14/09/06 14:55 plugins/org.jbpm.gd.jpdl.help_3.0.11.jar
| 754909 14/09/06 14:55 plugins/org.jbpm.gd.jpdl.ui_3.0.11.jar
| 1960 14/09/06 14:26 readme.html
| 282 14/09/06 14:26 site.xml
| -------- -------
| 10372958 39 files
Do I need to manually install something on eclipse before installing the designer?
Regards and thanks for anwering.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971547#3971547
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971547
19 years, 6 months
[Design of JBoss jBPM] - Re: MessageService and JMS
by tom.baeyens＠jboss.com
first of all a remark. i understand your frustrations. we are finishing a big restructuring of the jbpm source code base. also the build scripts still have quite some rough edges. please bear with us. it's normal that you experience some problems in the new structure. let us know your problems. we are eager to get it right asap.
FYI: main reason for this restructuring is better alignment with the multi process language approach that we're heading towards.
i added the file upload lib to the console build script. thanks.
about the /jbpm web-uri: i suppose that this change was necessary to get the designer working with the web console, right ? the default proposed deployment url is now /jbpm. jbpm-console.war fits better with our new naming scheme. also i like the /jbpm-console URI better then /jbpm. so we'll update the default that is presented in the deployment tab in the eclipse designer. would that resolve your second issue.
i'll now take a look at your oracle error.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971543#3971543
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971543
19 years, 6 months
[Design of JBoss jBPM] - Re: MessageService and JMS
by mteira
I've been fighting against the ant build files, my ignorance and the jBPM CVS to finally, be able to deploy the jbpm.ear inside my JBoss 4.0.4 GA.
My first question is about the changes I had to make. I want to think that at least some of them can be considered general fixes and not needed by an incorrect local setup. So, what is the preferred way to publish those changes? Just telling here? JIRA?
I'm running into problems now while trying to deploy a process from the graphical designer into Eclipse. I'm getting a very odd oracle exception complaining about a select sentence that seems to work fine when pasted into a SQLPlus session. I'm suspecting that perhaps hibernate version shipped with JBoss 4.0.4 GA could have some incompatibilities with the one needed by jBPM itself. I've pasted the full exception in the jBPM users forum as:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=90558
I'm using oracle datasources because I had bad experiences in the past with the READ_UNCOMMITED transaction isolation level of hypersonic, so I would like to test jBPM under a real world database (the one we are using in our production systems).
To avoid errors in the Uploader applet bundled in the console war (bundled in the jbpm.ear) I made the following changes in it s build.xml file:
### Eclipse Workspace Patch 1.0
| #P jbpm
| Index: console/build.xml
| ===================================================================
| RCS file: /cvsroot/jbpm/jbpm.3/console/build.xml,v
| retrieving revision 1.6
| diff -u -r1.6 build.xml
| --- console/build.xml 13 Sep 2006 17:57:06 -0000 1.6
| +++ console/build.xml 14 Sep 2006 10:29:08 -0000
| @@ -50,6 +50,7 @@
| <lib file="${lib.jsf.impl.local}" />
| <lib file="${lib.jsf.api.local}" />
| <lib file="${lib.facelets.local}" />
| + <lib file="${lib.commons.fileupload.local}" />
|
| <!-- jbpm web application classes -->
| <classes dir="target/classes" />
|
Also, to be able to deploy from the designer, I needed to change (again) the application.xml for the jbpm.ear:
### Eclipse Workspace Patch 1.0
| #P jbpm
| Index: enterprise/ear/src/main/resources/META-INF/application.xml
| ===================================================================
| RCS file: /cvsroot/jbpm/jbpm.3/enterprise/ear/src/main/resources/META-INF/application.xml,v
| retrieving revision 1.2
| diff -u -r1.2 application.xml
| --- enterprise/ear/src/main/resources/META-INF/application.xml 28 Aug 2006 14:06:02 -0000 1.2
| +++ enterprise/ear/src/main/resources/META-INF/application.xml 14 Sep 2006 10:30:56 -0000
| @@ -6,7 +6,10 @@
| <display-name>jbpm-enterprise-beans</display-name>
|
| <module>
| - <war>jbpm-console.war</war>
| + <web>
| + <web-uri>jbpm-console.war</web-uri>
| + <context-root>/jbpm</context-root>
| + </web>
| </module>
|
| <module>
|
So, now I'm stucked with that Oracle error, trying to deploy a process into JBPM to start testing JMS Message Service.
Any hint about that error?
Thanks a lot.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971523#3971523
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971523
19 years, 6 months
[Design of POJO Server] - Minimal now boots
by adrian＠jboss.org
I've got the minimal server booting using the new deployers.
There is a strange exception at shutdown:
| 12:24:06,448 WARN [ServiceClassLoaderDeployer] Error unregistering ucl: org.jboss.mx.loading.UnifiedClassLoader3@e8a021{ url=file:/home/ejort/mc-vdf-work/build/output/jboss-5.0.0.Beta/server/minimal/conf/jboss-service.xml ,addedOrder=2} for file:/home/ejort/mc-vdf-work/build/output/jboss-5.0.0.Beta/server/minimal/conf/jboss-service.xml
| java.lang.NullPointerException
| at org.jboss.mx.loading.UnifiedLoaderRepository3.removeClassLoader(UnifiedLoaderRepository3.java:897)
| at org.jboss.mx.loading.RepositoryClassLoader.unregister(RepositoryClassLoader.java:258)
| at org.jboss.mx.loading.UnifiedClassLoader.unregister(UnifiedClassLoader.java:196)
| at org.jboss.system.deployers.ServiceClassLoaderDeployer.internalRemoveClassLoader(ServiceClassLoaderDeployer.java:163)
| at org.jboss.system.deployers.ServiceClassLoaderDeployer.removeTopLevelClassLoader(ServiceClassLoaderDeployer.java:135)
| at org.jboss.deployers.plugins.deployers.helpers.AbstractTopLevelClassLoaderDeployer.removeClassLoader(AbstractTopLevelClassLoaderDeployer.java:45)
| at org.jboss.deployers.plugins.structure.AbstractDeploymentContext.removeClassLoader(AbstractDeploymentContext.java:346)
| at org.jboss.deployers.plugins.deployment.MainDeployerImpl.process(MainDeployerImpl.java:330)
| at org.jboss.deployers.plugins.deployment.MainDeployerImpl.shutdown(MainDeployerImpl.java:387)
| at org.jboss.system.server.profileservice.ServerImpl$ShutdownHook.shutdownDeployments(ServerImpl.java:750)
| at org.jboss.system.server.profileservice.ServerImpl$ShutdownHook.shutdown(ServerImpl.java:732)
| at org.jboss.system.server.profileservice.ServerImpl$ShutdownHook.run(ServerImpl.java:721)
|
|
I don't see why this doesn't happen in jboss-head?
It also does the double removeClassLoader()
* When the classloader is unregistered from the MBeanServer
* When ucl.unregister() is invoked
Maybe it is just eating the exception?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971521#3971521
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971521
19 years, 6 months
[Design of JBoss Remoting, Unified Invokers] - Re: Have remoting support a non invocation based model
by timfox
"tom.elrod(a)jboss.com" wrote : Below is list of possible scenarios for making remote calls through remoting.
|
| Legend:
| thread blocks = --|
| thread returns = -->
|
| 1. synchronous call
|
| caller thread -- remoting client --| -- NETWORK -- pooled processing thread -- handler
|
| Calling thread goes through remoting client call stack till makes network call and blocks for response. The pooled processing thread will call on the handler, get the response from the handler and write it back to the network where will be picked up by the blocking caller thread.
|
| 2. asynchronous call - client side
|
| caller thread --> remoting client (worker thread) --| -- NETWORK -- pooled processing thread -- handler
|
| Calling thread makes invocation request and returns before making network invocation. Remoting client pooled thread takes invocation and makes call over the network. From here is same as case 1, but response is just thrown away.
|
|
If you are going to throw it away, why write it on the server side in the first place? Seems wasteful.
anonymous wrote :
| 3. asynchronous call - server side
|
| caller thread -- remoting client --| -- NETWORK -- pooled processing thread --> pooled async processing thread -- handler
|
| Calling thread goes through remoting client call stack till makes network call and blocks for response. The pooled processing thread will hand off invocation to a pooled async processing thread and will return (thus unblocking the calling thread on the client). The pooled async processing thread will call on handler, get response, and throw it away.
|
|
Again - why write it in the first place?
anonymous wrote :
|
| 4. non-blocking asynchronous call
|
| caller thread -- remoting client --> -- NETWORK -- pooled processing thread -- handler
|
| Calling thread goes through remoting client call stack till makes network call where will only write to network, but not wait (block) for server response (see http://jira.jboss.com/jira/browse/JBREM-548). The pooled processing thread will call on the handler, get the response from the handler and write it back to the network.
|
|
Again, writing the response seems pointless. Only causes extra traffic and context switches.
anonymous wrote :
| Not sure yet what will have to be done for this implementation as don't know if will be a problem with pooled processing thread sending data back to network with no one on the other side.
|
So why send it?
anonymous wrote :
| Note: in the above scenarios, there is actually an accept thread on server that gets socket from server socket and passes onto a pooled processing thread and goes back to listening for next socket request. Have removed it from thread stack diagram to make easier to read.
|
| 1 - 3 are already available within remoting today. 4 is scheduled to be implemented. For 2 - 4, only getting request to server is covered. Getting response back to client will require callbacks. Also important to remember that remoting has one API that all the transport implementations support. In order to change that API for new desired behavior, all the transports must be able to support it (how it supports it is an implementation detail).
|
|
If the API is extended, surely existing transports are unaffacted, they can throw UnsupportedOperationException for any new methods, which won't be called by old user code anyway
I guess I should clarify where we are coming from here.
In messaging we need to provide very high throughput, in a different league to your normal ejb installation. We're talking up to 100s of thousands of messages per sec (depending on network) and these are 1 or 2K messages.
When we are benchmarked against our competitors it doesn't really matter how much our core code is optimised if we aren't efficiently handling the network transport. This is where we will be killed.
Any extra reads or writes or threads blocking when they don't need to do will contribute to that.
A request-response model is great for RPC style usage patterns, but IMHO doesn't really suit what we need in messaging.
Also in the future we probably need to provide wire format compatibility with other protocols so our requirements are very specific:
For our socket transport we need a single TCP connection that can be read from and written to in a non blocking fashion from both ends.
On the server side we want to do something like the following:
1 Data is read (non blocking) from channel by acceptor thread and work is handed off to worker.
2 The work may be passed between one or more worker threads each of which is specialised for a particular type of work. Each worker threads basically goes around in its own loop. This is basically a SEDA style model and gives us great throughput and scalability w.r.t. number of concurrent "requests" since there is no thread per request and there are far less context switches. We already have the SEDA machinery in place in JBM, the last piece of the puzzle that is missing is the support from remoting for the non blocking functionality.
3 For some incoming data it may be necessary to write some outgoing data back to the socket. Note this is done on a completely different thread to the acceptor thread and the acceptor thread may have served many more incoming data in the mean-time.
It's also crucial to us that we only use a single TCP connection and concurrent requests are multiplexed over that -i.e. we don't want a socket pool as is currently the case with the socket transport.
Actually, if the channel abstraction is bidirectional then multiplexing becomes straightforward too. You simply need to wrap the data requests and responses in a packet with a header identifying the "logical" connection and correlate them on receipt.
I don't think it would be hard to write such a transport (in fact some tools such as Apache MINA make it almost trivial - although I am not sure we should be using that library) and we in JBM would love to do so and contribute it back to remoting.
The problem I have right now is that the remoting's conceptual model of invocations seems so far removed from the model we require I don't know how we could shoe-horn it in to fit.
There is some analogy to the servlet API here. The servlet API was designed a long time ago when everyone was using the blocking IO api (there was no Java NBIO of course) to write server applications that had the classic thread per request, blocking on accept, thread pool model.
As we all know, since the servlet API basically assumes a request/response model it makes it very hard (impossible) to reconcile with a decoupled request/response approach. So basically any servlet applications are doomed to not really benefit from non blocking IO.
Remoting also assumes an invocation based model, so IMHO suffers from the same problems.
My personally opinion is that you guys you should extend the great work you have done with remoting to date by extending the API to support the newer approach, otherwise it's going to be hard for high performance applications like us to use it. And this will be more so going ahead, as more people throw out their blocking IO.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971508#3971508
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3971508
19 years, 6 months