[JBoss JIRA] Created: (JBAS-8401) exception is thrown by javax.ejb.EJBLocalObject.isIdentical -- ejb2.x
by Thunder Lei (JIRA)
exception is thrown by javax.ejb.EJBLocalObject.isIdentical -- ejb2.x
---------------------------------------------------------------------
Key: JBAS-8401
URL: https://jira.jboss.org/browse/JBAS-8401
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB2, EJB3
Affects Versions: JBossAS-5.0.0.GA
Environment: Microsoft Windows XP [Version 5.1.2600]
jdk160_10
Reporter: Thunder Lei
Assignee: Alexey Loubyansky
I am new to JBoss community. If I don't report the issues correctly, pls help correct me.
I develop a stateless session bean, in which EJB2.x and EJB3 interfaces coexist.
In short, it works, but with two issues.
1. unable to override 2.x local home jndi name.
In jboss.xml (jboss_5_0.dtd), the local home jndi is NOT allowed, so you have to refer to the default local home jndi -- beanName/local
2. when calling method on remote business interface, it works, but EJB exception is thrown by javax.ejb.EJBLocalObject.isIdentical.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 8 months
[JBoss JIRA] Commented: (JGRP-1038) FC2
by Bela Ban (JIRA)
[ https://jira.jboss.org/browse/JGRP-1038?page=com.atlassian.jira.plugin.sy... ]
Bela Ban commented on JGRP-1038:
--------------------------------
Looks like FC2 handles only *unicasts*, not multicasts. Is this what FC2's supposed to do ? If so, it could be an alternative to UFC... A good perf test would be UnicastTestRpcDist.
> FC2
> ---
>
> Key: JGRP-1038
> URL: https://jira.jboss.org/browse/JGRP-1038
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 2.11
>
> Attachments: FC2.java, FCOverloadTest.java, Results.txt
>
>
> [Email Gray Watson]
> So we implemented our own FC2 because of problems with FC. I've been writing
> tests and trying (with some success) to reproduce the issues we faced.
> Initially when we were doing performance tests in our cluster of ~20 big-ish
> linux servers with UDP/FC, we saw severe performance tests with "decent"
> sized messages. Often we have large SQL responses which are in the 1+mb
> range and can be as high as 10+mb. I decided to write the attached
> FCOverloadTest to demonstrate some of the issues and to compare FC and FC2.
> The default FC setting max_credits=500000 in udp.xml results in terrible
> performance -- 952 seconds to send 10x 5mb messages to 10 hosts (500mb).
> Less than optimal.
> The simple solution, on the surface, is to increase the credits 1 or 2
> orders of magnitude. 5000000 takes 160 secs, and 50000000 takes 32 secs.
> Fine. But this in effect removes most of the flow-control. The larger the
> max-credits, the more messages queue up.
> What I thought would be a better flow-control model was per-recipient, where
> each sender would keep a "water-level" of the outstanding packets needed to
> be ack'd. When the water level got too high it would pause the sender until
> the receiver had ack'd the water level back down. This is what FC2 tried to
> accomplish. I've attached my test results, the FCOverloadTest, and FC2.
> FC2 looks to do less UNICAST retransmits, sends fewer packets, and is
> faster. It needs some review however.
> I'd like to know other folks' experiences with flow-control. Are people
> really using the udp.xml settings in production? What message sizes do you
> have?
> The next step in my testing is to write some unit tests which shut down and
> start up notes while the system is loaded with an attempt to reproduce the
> cluster pauses with FC that we have seen which would be deadly to our
> application.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 8 months
[JBoss JIRA] Assigned: (JBAS-8276) Weld Extension vs. Tomcat deployer in JBoss 6
by Heiko Braun (JIRA)
[ https://jira.jboss.org/browse/JBAS-8276?page=com.atlassian.jira.plugin.sy... ]
Heiko Braun reassigned JBAS-8276:
---------------------------------
Assignee: Heiko Braun (was: Marius Bogoevici)
> Weld Extension vs. Tomcat deployer in JBoss 6
> ---------------------------------------------
>
> Key: JBAS-8276
> URL: https://jira.jboss.org/browse/JBAS-8276
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Weld/CDI
> Affects Versions: 6.0.0.M4
> Reporter: Heiko Braun
> Assignee: Heiko Braun
>
> When I deploy a web application that contains CDI beans to JBoss6-M4 I can see that bean deployment being executed two times. First the CDI deployer kicks in, then Tomcat deployer re-deploys the war archive, which causes a second execution of the extension:
> 12:20:34,082 INFO [org.jboss.weld.Version] WELD-000900 1.0.1 (SP4)
> 12:20:34,516 INFO [org.jboss.errai.cdi.server.CDIExtensionPoints] Discovered Errai Service: class com.foo.server.HelloWorldService
> 12:20:34,564 INFO [org.jboss.errai.cdi.server.CDIExtensionPoints] Register CDI component as MessageCallback: @Service @ApplicationScoped com.foo.server.HelloWorldService
> 12:20:34,583 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] deploy, ctxPath=/funky-app
> 12:20:34,720 INFO [org.jboss.resteasy.cdi.CdiInjectorFactory] Found BeanManager at java:comp/BeanManager
> 12:20:39,776 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] undeploy, ctxPath=/funky-app
> 12:20:40,246 INFO [org.jboss.weld.Version] WELD-000900 1.0.1 (SP4)
> 12:20:40,733 INFO [org.jboss.errai.cdi.server.CDIExtensionPoints] Discovered Errai Service: class com.foo.server.HelloWorldService
> 12:20:40,844 INFO [org.jboss.errai.cdi.server.CDIExtensionPoints] Register CDI component as MessageCallback: @Service @ApplicationScoped com.foo.server.HelloWorldService
> 12:20:40,856 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] deploy, ctxPath=/funky-app
> 12:20:40,929 INFO [org.jboss.resteasy.cdi.CdiInjectorFactory] Found BeanManager at java:comp/BeanManager
> Shouldn't it be the execution the extension tight to the tomcat deployer lifecycle? I.e. be dependent on it's meta data?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 8 months
[JBoss JIRA] Created: (EJBTHREE-2167) @TransactionAttribute declared in superclass is ignore & @TransactionAttribute conflict to Deployment Descriptor
by e t (JIRA)
@TransactionAttribute declared in superclass is ignore & @TransactionAttribute conflict to Deployment Descriptor
----------------------------------------------------------------------------------------------------------------
Key: EJBTHREE-2167
URL: https://jira.jboss.org/browse/EJBTHREE-2167
Project: EJB 3.0
Issue Type: Bug
Components: ejb3
Environment: jboss-5.1.0.GA
Sun jdk1.6.0_16
WinXP 32bit
Reporter: e t
Attachments: src.rar
According to the EJB3 Specification,If the bean class has superclasses, the following additional rules apply.
• A transaction attribute specified on a superclass S applies to the business methods defined by S. If a class-level transaction attribute is not specified on S, it is equivalent to specification of TransactionAttribute(REQUIRED) on S.
• A transaction attribute may be specified on a business method M defined by class S to override for method M the transaction attribute value explicitly or implicitly specified on the class S.
• If a method M of class S overrides a business method defined by a superclass of S, the transaction attribute of M is determined by the above rules as applied to class S.
The issue is :
1 . When I take the test of a SLSB which has a superclass and its transaction attribute is set to NEVER, I always get the method call in transaction attribute is set to REQUIRED(see the follow code for details).
2 . When I deploy an empty ejb-jar.xml and jboss.xml to META-INF directory, the SLSB's transaction attribute is set to SUPPORTS/NOT_SUPPORTEDNEVER
PS:I using the EntityManager's persist method call for checking current method call is associated with a transaction.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 8 months