April 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (EJBTHREE-651) javax.ejb.SessionContext.getBusinessObject has wrong signature

by Carlo de Wolf (JIRA)

javax.ejb.SessionContext.getBusinessObject has wrong signature -------------------------------------------------------------- Key: EJBTHREE-651 URL: http://jira.jboss.com/jira/browse/EJBTHREE-651 Project: EJB 3.0 Issue Type: Bug Reporter: Carlo de Wolf javax.ejb.SessionContext.getBusinessObject must have the following signature: <T> T getBusinessObject(Class<T> businessInterface) throws IllegalStateException; See http://java.sun.com/javaee/5/docs/api/javax/ejb/SessionContext.html#getBu... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 7 months

2
6
0 / 0

[JBoss JIRA] Created: (JBCACHE-931) Move to JBossAOP rather than hand-wiring interceptor chain for JBoss Cache

by Manik Surtani (JIRA)

Move to JBossAOP rather than hand-wiring interceptor chain for JBoss Cache -------------------------------------------------------------------------- Key: JBCACHE-931 URL: http://jira.jboss.com/jira/browse/JBCACHE-931 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.0.0.GA Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.1.0.GA This should be a seamless change for end-users, and backward compat should be maintained. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 7 months

3
6
0 / 0

[JBoss JIRA] Created: (JBREM-706) In socket transport, prevent client side oneway invocations from artificially reducing concurrency

by Ron Sigal (JIRA)

In socket transport, prevent client side oneway invocations from artificially reducing concurrency -------------------------------------------------------------------------------------------------- Key: JBREM-706 URL: http://jira.jboss.com/jira/browse/JBREM-706 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.2.0.Beta2 (Bluto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.0.Beta2 (Bluto) There is a subtle problem with the handling of client side oneway invocations in the socket transports (and descendants). After the invocation has been marshalled to the wire, the connection is returned to the connection pool, from which it can be reused, even if the server side handler is still processing the previous invocation. Consequently, invocations can back up and run serially instead of running concurrently. The following dialogue exposes the problem and possible solutions: =============================================================================================================== Ron Sigal wrote Hi Tom, I just noticed an interesting phenomenon that I wanted to tell you about. Maybe it'll be obvious to you, but it surprised me. I'm writing unit tests for socket and http, since they behave differently on oneway invocations. I've got a oneway ThreadPool with two threads and I make 4 oneway invocations, one right after the other. The handler waits for 5 seconds before returning. I expected that they would all run on the server simultaneously, but they don't. What happens is something like this: (1) invocation 1 gets made on thread 1 and socket connection 1 to ServerThread 1 is created; (2) invocation 2 gets made on thread 2 and socket connection 2 to ServerThread 2 gets created; (3) invocation 3 gets made on thead 1 and socket connection 1 gets reused. But ServerThread 1 is still sleeping, so invocation 3 waits for 5 seconds. Not a big deal, but I might not have guessed it if I hadn't seen it. =============================================================================================================== Ron Sigal wrote Hi Tom, Well, it's stranger than I thought. It turns out that for client side oneway invocations, socket, which returns immediately after marshaling the invocation, can be slower than http, which waits for a response. Consider a client side oneway threadpool with 2 threads and a queue of size 1, and suppose there are 4 invocations in quick succession. The handler takes 5 seconds per invocation. http: 1. 1st invocation runs in the first threadpool thread. 2. 2nd invocation runs in the second threadpool thread 3. 3rd invocation goes on the queue 4 4th invocation runs on the main thread Assuming there are at least 3 server threads, invocations 1, 2, and 4 run in the first 5 seconds, and then invocation 3 runs. Total time 10 seconds. socket (one possible scenario): 1. 1st invocation runs in the first threadpool thread and returns the socket connection to the pool 2. 2nd invocation runs in a threadpool thread, finds the pooled connection, marshals the invocation, and returns the connection to the pool. On the server side, the ServerThread runs the invocations after finishing the 1st invocation. 3. 3rd invocation runs in a threadpool thread, finds the pooled connection, marshals the invocation, and returns the connection to the pool. On the server side, the ServerThread runs the invocations after finishing the 2nd invocation. 4. 4th invocation runs in a threadpool thread, finds the pooled connection, marshals the invocation, and returns the connection to the pool. On the server side, the ServerThread runs the invocations after finishing the 3rd invocation. Total time: 20 seconds. I've seen this happen. The scary thing is that the story scales. With more threads on the client side and server side, http can run more and more invocations in parallel. Whereas socket could end up running arbitrarily many invocations serially. I think that having MicroSocketClientInvoker return after marshaling a client side oneway invocation isn't a good idea. Ovidiu's JBREM-685 ( <http://jira.jboss.com/jira/browse/JBREM-685>A server needs redundant information to detect a one way invocation) <http://jira.jboss.com/jira/browse/JBREM-685> gives me a half baked idea. Maybe these two ways of tagging a oneway invocation could be used to distinguish client side from server side oneway invocations. Or something like that. By the way, I think that there's no problem with server side oneway invocations, since a single ServerInvoker can keep shoving invocations into the threadpool. -Ron =============================================================================================================== Tom Elrod wrote: Wow. Never thought about this happening but makes sense. So the real problem with the socket client invoker is it pools the connections when doing oneway invocations. So it is queuing up invocations on the same connection which can only be processed serially on the server side. Think maybe your idea about using the ONEWAY_FLAG on the client can work. Basically am thinking we'd have to check that before returning the connection to pool and if is set, then throw away the connection (i.e. don't put back in pool). This way, the next oneway invocation would not be using the same connection and on the server side, should use another available server thread to do the process (so could be in parallel). However, this means that incur more overhead on the client side to create a new connection for each oneway invocation, but is maybe worth the cost (too bad we can't tell if serve will take a long time or not). Let me know what you think. =============================================================================================================== Ron Sigal wrote: It seems to me that MicroSocketClientInvoker could: ... 2. in the case of client side oneway invocations, either throw away the connection and return immediately, or just not return until it gets a response from the server. Since it's on a separate thread, maybe the latter is preferable, since then it can return the connection to the pool after it gets a response. =============================================================================================================== Tom Elrod wrote: Yeah, this is a tricky one. On the one hand, if don't throw away the connection and wait for the server response AND the server takes a long time, would be possible to exhaust the pool since all threads will be stuck waiting for server to respond. With the new change to the thread pool to use the RUN mode, would mean calling threads would then be making the remote call and would pretty much be negating the purpose of oneway client side (since client caller thread would be making the network call and blocking until gets response). However, if do throw away the connection, then means that in general have defeated purpose of connection pooling since will have to create a new connection each time oneway client side invocations are made. So if the server processes the requests quickly, would be taking on the extra overhead of creating a new client connection for every call. Hmmm. Could go either way if feel strongly one way or another. However think I am leaning towards throwing away the connection. =============================================================================================================== Ron Sigal wrote: This might be complicating things, but for client side oneway invocations we could set a short per invocation timeout, say 1 second or 5 seconds. If the response comes back, put the connection back in the pool. If it times out, throw the connection away. Don't know how to pick the timeout, though. =============================================================================================================== Tom Elrod wrote: I hate getting too complicated as tends to increase the chance of introducing bugs. However, if wanted to do this, would say need to make the timeout very low, i.e. 1 second. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 7 months

1
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-876) Up-port to trunk of EJBTHREE-875

by Carlo de Wolf (JIRA)

Up-port to trunk of EJBTHREE-875 -------------------------------- Key: EJBTHREE-876 URL: http://jira.jboss.com/jira/browse/EJBTHREE-876 Project: EJB 3.0 Issue Type: Sub-task Reporter: Carlo de Wolf Fix For: EJB 3.0 RC11 - FD -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-911) manage remote dependency injection

by William DeCoste (JIRA)

manage remote dependency injection ---------------------------------- Key: EJBTHREE-911 URL: http://jira.jboss.com/jira/browse/EJBTHREE-911 Project: EJB 3.0 Issue Type: Feature Request Reporter: William DeCoste Assigned To: William DeCoste There are two EJBs, A and B, which are deployed in different JBoss instances. A reference of the EJB B should be injected in the EJB A. But if during deployment of A, the instance of the EJB B is not running, the injection can not succeed. It would be great feature, that the injection in A can succeed, after the EJB B is deployed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 7 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAOP-380) JBoss AOP sets info field to null before rebuilding a chain

by Flavia Rainone (JIRA)

JBoss AOP sets info field to null before rebuilding a chain ----------------------------------------------------------- Key: JBAOP-380 URL: http://jira.jboss.com/jira/browse/JBAOP-380 Project: JBoss AOP Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.alpha4, 1.5.5.GA Reporter: Flavia Rainone Fix For: 1.5.6.GA, 2.0.0.alpha5 Advisor sets the joinpoint info field as null before rebuilding the interceptor chain. So, for a short period of time, that joinpoint will not be intercepted. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 7 months

3
16
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-137) Move the load balance policies from the AS cluster module

by Brian Stansberry (JIRA)

Move the load balance policies from the AS cluster module --------------------------------------------------------- Key: JBCLUSTER-137 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-137 Project: JBoss Clustering Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Need to decide with Tom Elrod whether these belong in clustering or remoting. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 7 months

2
2
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-138) Move or replace ClusteringTargetsRepository and FamilyClusterInfo

by Brian Stansberry (JIRA)

Move or replace ClusteringTargetsRepository and FamilyClusterInfo ----------------------------------------------------------------- Key: JBCLUSTER-138 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-138 Project: JBoss Clustering Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: Q3Y6 Work with Tom Elrod to determine what's going to generically provide the functionality that ClusteringTargetsRepository and FCI do. When we do this we have to keep in mind the old detached invokers (unless we decide to get rid of them.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 7 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-4322) Wrong context path in Embedded JBoss JAR deployment

by Christian Bauer (JIRA)

Wrong context path in Embedded JBoss JAR deployment --------------------------------------------------- Key: JBAS-4322 URL: http://jira.jboss.com/jira/browse/JBAS-4322 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Deployment services Reporter: Christian Bauer Assigned To: Dimitris Andreadis Embedded JBoss build from SVN trunk yesterday: 07:47:14,079 DEBUG [MainDeployerImpl] Add deployment context: vfsjar:file:/Users/turin/work/seamng/app/lib/seamng-config.jar!/deployers/deployers/aspect-deployer-beans.xml 07:47:14,082 ERROR [MainDeployerImpl] Unable to determine structure of deployment: vfsjar:file:/Users/turin/work/seamng/app/lib/seamng-config.jar!/deployers/deployers/aspect-deployer-beans.xml org.jboss.deployers.spi.DeploymentException: Failed to process context: vfsjar:file:/Users/turin/work/seamng/app/lib/seamng-config.jar!/deployers/deployers/aspect-deployer-beans.xml at org.jboss.deployers.plugins.structure.DefaultStructureBuilder.populateContext(DefaultStructureBuilder.java:94) at org.jboss.deployers.plugins.deployment.MainDeployerImpl.determineStructure(MainDeployerImpl.java:684) at org.jboss.deployers.plugins.deployment.MainDeployerImpl.addDeploymentContext(MainDeployerImpl.java:352) at org.jboss.embedded.DeploymentGroup.add(DeploymentGroup.java:164) at org.jboss.embedded.DeploymentGroup.addVirtualFiles(DeploymentGroup.java:205) at org.jboss.embedded.DeploymentGroup.addDirectoryByResource(DeploymentGroup.java:471) at org.jboss.embedded.DeploymentScanner.start(DeploymentScanner.java:99) 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:103) at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:145) at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelControllerContextAction.java:197) at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.install(KernelControllerContextAction.java:136) at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:233) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:724) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:445) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:555) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:489) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:289) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:192) at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:302) at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:272) at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:119) at org.jboss.kernel.plugins.deployment.xml.BeanXMLDeployer.deploy(BeanXMLDeployer.java:96) at org.jboss.embedded.Bootstrap.deployBaseBootstrapUrl(Bootstrap.java:150) at org.jboss.embedded.Bootstrap.bootstrapURL(Bootstrap.java:162) at org.jboss.embedded.Bootstrap.bootstrap(Bootstrap.java:201) at org.jboss.embedded.Bootstrap.bootstrap(Bootstrap.java:214) at my.app.HelloWorld.main(HelloWorld.java:37) Caused by: java.io.FileNotFoundException: JarEntryHandler@10196585[path= context=jar:file:/Users/turin/work/seamng/app/lib/seamng-config.jar!/deployers/ real=jar:jar:file:/Users/turin/work/seamng/app/lib/seamng-config.jar!/deployers/!/deployers/] has no child: deployers at org.jboss.virtual.plugins.context.jar.JarEntryHandler.createChildHandler(JarEntryHandler.java:197) at org.jboss.virtual.plugins.context.AbstractVirtualFileHandler.structuredFindChild(AbstractVirtualFileHandler.java:280) at org.jboss.virtual.plugins.context.jar.JarEntryHandler.findChild(JarEntryHandler.java:171) at org.jboss.virtual.plugins.context.AbstractVFSContext.findChild(AbstractVFSContext.java:118) at org.jboss.virtual.VFS.findChild(VFS.java:205) at org.jboss.deployers.plugins.structure.DefaultStructureBuilder.populateContext(DefaultStructureBuilder.java:74) ... 34 more This is the JAR on my classpath: 0 Thu Apr 12 07:38:50 CEST 2007 conf/ 9374 Wed Apr 11 16:49:12 CEST 2007 conf/bootstrap-beans.xml 4437 Thu Apr 12 07:40:24 CEST 2007 conf/jboss-service.xml 11295 Wed Apr 11 16:49:12 CEST 2007 conf/jbossjta-properties.xml 0 Thu Apr 12 08:19:44 CEST 2007 deploy/ 22444 Wed Apr 11 16:49:12 CEST 2007 deploy/ejb3-interceptors-aop.xml 2402 Wed Apr 11 16:49:12 CEST 2007 deploy/jboss-local-jdbc.rar 2517 Wed Apr 11 16:49:12 CEST 2007 deploy/jboss-xa-jdbc.rar 0 Wed Apr 11 16:49:12 CEST 2007 deployers/ 504 Wed Apr 11 16:49:12 CEST 2007 deployers/aspect-deployer-beans.xml 5190 Wed Apr 11 16:49:12 CEST 2007 deployers/ejb3-deployers-beans.xml 1900 Wed Apr 11 16:49:12 CEST 2007 deployers/jca-deployers-beans.xml 194 Wed Apr 11 16:49:12 CEST 2007 jndi.properties If I have the same structure exploded on my classpath, it works. The JAR scanner adds a duplicate subdirectory name to the context path. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 7 months

3
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-906) @Service @Management are not creating the MBean properly

by Robb Greathouse (JIRA)

@Service @Management are not creating the MBean properly -------------------------------------------------------- Key: EJBTHREE-906 URL: http://jira.jboss.com/jira/browse/EJBTHREE-906 Project: EJB 3.0 Issue Type: Bug Components: EJB3 Extensions Affects Versions: EJB 3.0 RC9 - Patch 1 Environment: Tested on Solaris, Linux RHEL4, Windows Reporter: Robb Greathouse When defining MBeans and MBean services with annotations in EJB3.0 they fail to deploy. This is seen in our own TrailBlazer application which used to work. I can attach log files and source code if that would be helpful. Currently the feature is blocking Cisco a very large client that is pushing JBoss EJB3.0 to their customer base through their products. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 7 months

2
1
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2007