[Design of POJO Server] - Re: What's the status of HEAD?
by kabir.khan＠jboss.com
I've updated the thirdparty repository, so the aop problems have gone
I am however instead seeing some errors like this from the command-line
| java.lang.IllegalArgumentException: URI is not hierarchical
| at java.io.File.<init>(File.java:335)
| at org.jboss.virtual.plugins.context.file.FileSystemContext.getFile(FileSystemContext.java:69)
| at org.jboss.virtual.plugins.context.file.FileSystemContext.<init>(FileSystemContext.java:124)
| at org.jboss.virtual.plugins.context.file.FileSystemContextFactory.getVFS(FileSystemContextFactory.java:65)
| at org.jboss.virtual.VFS.getVFS(VFS.java:60)
| at org.jboss.system.server.profileservice.VFSScanner.getVFforURI(VFSScanner.java:691)
| at org.jboss.system.server.profileservice.VFSScanner.addURI(VFSScanner.java:275)
| at org.jboss.system.server.profileservice.VFSScanner.setURIList(VFSScanner.java:176)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:55)
| at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:108)
| at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
| at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:71)
| at org.jboss.kernel.plugins.dependency.ConfigureAction.setAttributes(ConfigureAction.java:97)
| at org.jboss.kernel.plugins.dependency.ConfigureAction.installAction(ConfigureAction.java:53)
| at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.install(KernelControllerContextAction.java:96)
| at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:226)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:709)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:429)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:538)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:472)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:274)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:177)
| at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:300)
| at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:270)
| at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:117)
| at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:64)
| at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:76)
| at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:145)
| at org.jboss.system.server.profileservice.ProfileServiceBootstrap.deploy(ProfileServiceBootstrap.java:290)
| at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:206)
| at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
| at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:401)
| at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:340)
| at org.jboss.Main.boot(Main.java:210)
| at org.jboss.test.server.profileservice.MainWithSimpleHotDeployTestCase.testDefaultStartup(MainWithSimpleHotDeployTestCase.java:105)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at junit.framework.TestCase.runTest(TestCase.java:154)
| at junit.framework.TestCase.runBare(TestCase.java:127)
| at junit.framework.TestResult$1.protect(TestResult.java:106)
| at junit.framework.TestResult.runProtected(TestResult.java:124)
| at junit.framework.TestResult.run(TestResult.java:109)
| at junit.framework.TestCase.run(TestCase.java:118)
| at junit.framework.TestSuite.runTest(TestSuite.java:208)
| at junit.framework.TestSuite.run(TestSuite.java:203)
| at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:297)
| at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:672)
| at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:567)
| 1047 [main] DEBUG org.jboss.system.server.profileservice.ProfileServiceBootstrap - Scanning for bootstrap resources: META-INF/defaulthotdeploy/deploy
| er-beans.xml
| 1063 [main] DEBUG org.jboss.system.server.profileservice.ServerImpl - Already in start, ignoring duplicate start
| 1063 [main] DEBUG org.jboss.system.server.profileservice.ServerImpl - Failed to start
| java.lang.RuntimeException: Exception during Bootstrap
| at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:99)
| at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:401)
| at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:340)
| at org.jboss.Main.boot(Main.java:210)
| at org.jboss.test.server.profileservice.MainWithSimpleHotDeployTestCase.testDefaultStartup(MainWithSimpleHotDeployTestCase.java:105)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at junit.framework.TestCase.runTest(TestCase.java:154)
| at junit.framework.TestCase.runBare(TestCase.java:127)
| at junit.framework.TestResult$1.protect(TestResult.java:106)
| at junit.framework.TestResult.runProtected(TestResult.java:124)
| at junit.framework.TestResult.run(TestResult.java:109)
| at junit.framework.TestCase.run(TestCase.java:118)
| at junit.framework.TestSuite.runTest(TestSuite.java:208)
| at junit.framework.TestSuite.run(TestSuite.java:203)
| at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:297)
| at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:672)
| at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:567)
| Caused by: org.jboss.deployers.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
|
| *** CONTEXTS IN ERROR: Name -> Error
|
| VFSDeploymentScanner -> java.lang.IllegalArgumentException: URI is not hierarchical
|
|
| at org.jboss.system.server.profileservice.ProfileServiceBootstrap.checkIncomplete(ProfileServiceBootstrap.java:384)
| at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:235)
| at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
| ... 19 more
|
|
>From eclipse it runs fine
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975463#3975463
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975463
19 years
[Design of JBoss ESB] - Re: GpListener reload config - new instance of listeners?
by mark.little＠jboss.com
Mark:
anonymous wrote :
| Johan,
|
| Other listeners that are triggered from the GpListener face a situation that is similar to what you're talking about. They can only do so because there is no problem in having more than one instance of the class.
|
I haven't checked the code (and probably won't get a chance until after I finish the merge), but doesn't this open up a potential threading problem? Suppose the current listeners (or a subset of them) are blocked (or looping, maybe consuming cycles) and can't return and there is some fundamental issue that then causes subsequently created listeners to also enter this loop. We'll keep creating more and more threads and eventually kill the VM/machine.
anonymous wrote :
| The JmsQueueListener is a good example: it could wait forever to obtain a message from a JMS queue. Instead of this it will wait at most until the GpListener is about to reload it's parameters. (See receive() method in JmsQueueListener.java lines 107 to 111 where it determines how much to wait and when to end looping). If a message was received (or an HttpRequest in your case) before that time is expired, it will instantiate the corresponding action class (it has now evolved into a sequence of actions) in a child thread. Once the time has come for the GpListener to reload it's parameters, the JmsQueueListener receive() method will end, and so will the thread in which it's running. In this class, there's really no conflict in having two or more instances of JmsQueueListener.
|
| The situation is slightly different when you are listening and (more importantly) responding in a well known port. In that case, you don't wish to have anybody else (not even other instances of the class that's listening) using the same port, until the running instance ends, and so does any class that needs the port. So we would have to think of a mechanism ( e.g. a 'singleton=true' in configuration) to enable some 'controlled' listeners (those that are instantiated from the GpListener) to wait for active instances to finish before re-instantiating with the values that came from the latest parameter reload.
|
| Whereas the GpListener class would have to change to reflect this requirement, it would still be essential to allow for some kind of parameter reloading mechanism, and whatever that might be (synchronous or asynchronous), we would still have to deal with the same situation: a sequence of actions that is still working and needing to respond in a specific port, and some new instance of a listener trying to use the same port.
|
Or the act of creating new listeners is configurable. Maybe something like (in XML as an example config) ...
| <gplistener>
| <listeners>
| <jms-listener>
| <!-- various config -->
| </jms-listener>
| <http-listener create_new=false>
| <!-- various config -->
| </http-listener>
| <ftp-listener create_new=true> <!-- just to show that create_new default is true -->
| <!-- various config -->
| </listeners>
| </gplistener>
|
anonymous wrote :
| Current behaviour of the GpListener does not affect child listeners that don't need to be singletons. It doesn't matter how many processes are polling the same directory as long as they don't step on each others' toes (for example by trying to process the same file). Same with SqlTablePollers and even easier with JmsQueueListeners.
|
| My recommendation would be to continue to test your Http listener class, triggering action classes that will process the request and at some point submit a response. In order to do that, and avoiding the noise of parameter reloading,
|
This does worry me though: what overhead does reloading the parameters put on us?
Does reloading of parameters happen solely to recreate the listeners, or is it also to cope with the possibilities that the parameters may have changed?
anonymous wrote :
| simply put a huge value in parameterReloadSecs attribute. That will temporarily allow you to tune your Http listener, while we think of (and hopefully put in place) an acceptable solution for the GpListener.
|
I agree. No change is going to happen in the next day or so ;-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975459#3975459
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975459
19 years
[Design of JBoss ESB] - Re: GpListener reload config - new instance of listeners?
by mark.little＠jboss.com
Esteban:
Johan,
Other listeners that are triggered from the GpListener face a situation that is similar to what you're talking about. They can only do so because there is no problem in having more than one instance of the class.
The JmsQueueListener is a good example: it could wait forever to obtain a message from a JMS queue. Instead of this it will wait at most until the GpListener is about to reload it's parameters. (See receive() method in JmsQueueListener.java lines 107 to 111 where it determines how much to wait and when to end looping). If a message was received (or an HttpRequest in your case) before that time is expired, it will instantiate the corresponding action class (it has now evolved into a sequence of actions) in a child thread. Once the time has come for the GpListener to reload it's parameters, the JmsQueueListener receive() method will end, and so will the thread in which it's running. In this class, there's really no conflict in having two or more instances of JmsQueueListener.
The situation is slightly different when you are listening and (more importantly) responding in a well known port. In that case, you don't wish to have anybody else (not even other instances of the class that's listening) using the same port, until the running instance ends, and so does any class that needs the port. So we would have to think of a mechanism ( e.g. a 'singleton=true' in configuration) to enable some 'controlled' listeners (those that are instantiated from the GpListener) to wait for active instances to finish before re-instantiating with the values that came from the latest parameter reload.
Whereas the GpListener class would have to change to reflect this requirement, it would still be essential to allow for some kind of parameter reloading mechanism, and whatever that might be (synchronous or asynchronous), we would still have to deal with the same situation: a sequence of actions that is still working and needing to respond in a specific port, and some new instance of a listener trying to use the same port.
Current behaviour of the GpListener does not affect child listeners that don't need to be singletons. It doesn't matter how many processes are polling the same directory as long as they don't step on each others' toes (for example by trying to process the same file). Same with SqlTablePollers and even easier with JmsQueueListeners.
My recommendation would be to continue to test your Http listener class, triggering action classes that will process the request and at some point submit a response. In order to do that, and avoiding the noise of parameter reloading, simply put a huge value in parameterReloadSecs attribute. That will temporarily allow you to tune your Http listener, while we think of (and hopefully put in place) an acceptable solution for the GpListener.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975456#3975456
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975456
19 years