[JBoss JIRA] (JBWEB-263) Remove WeakHash map from BeanELResolver and depend on proper callback to remove bean properties
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/JBWEB-263?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski edited comment on JBWEB-263 at 3/27/13 10:04 AM:
--------------------------------------------------------------------
It seems to work. One side note, I took time to test one thing. Not sure if this is a "seam" thing. When sun classes are pocked, they create BeanELResolver instance(B1). However when SEAM kicks in, for every app(B1+n)(or context, not quite sure) it creates another instance. Even though SEAM does that, this particular instance is not used, the B1 is used for all invocations.
was (Author: baranowb):
It seems to work. One side note, I took time to test one thing. Not sure if this is a "seam" thing. When sun classes are pocked, they create BeanELResolver instance(B1). However when SEAM kicks in, for every app(B1+n)(or context, not quite sure) it creates another instance. Even though SEAM does that, this particular is not used, the B1 is used for all invocations.
> Remove WeakHash map from BeanELResolver and depend on proper callback to remove bean properties
> -----------------------------------------------------------------------------------------------
>
> Key: JBWEB-263
> URL: https://issues.jboss.org/browse/JBWEB-263
> Project: JBoss Web
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Bartosz Baranowski
> Assignee: Remy Maucherat
> Attachments: JBWEB-263.patch, JBWEB-263.patch
>
>
> As in subject. Even though its a weakhashmap( and current source has the ConcurrentCache.
> Affected version: 2.1.12.GA - http://svn.jboss.org/repos/jbossweb/branches/2.1.x/
> Fix version: next( EAP depends on 2.1.13.GA-patch01 or JBOSSWEB_2_1_12_GA_patch03 )
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] (AS7-6664) Unable to turn on/off logging handlers using enable()/disable() in CLI
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6664?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6664:
----------------------------------------------
Radim Hatlapatka <rhatlapa(a)redhat.com> changed the Status of [bug 915317|https://bugzilla.redhat.com/show_bug.cgi?id=915317] from ON_QA to ASSIGNED
> Unable to turn on/off logging handlers using enable()/disable() in CLI
> ----------------------------------------------------------------------
>
> Key: AS7-6664
> URL: https://issues.jboss.org/browse/AS7-6664
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management, Logging
> Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final)
> Reporter: Brian Stansberry
> Assignee: James Perkins
> Fix For: 8.0.0.Alpha1
>
>
> Peter Kremens reports:
> I am unable to use enable/disable operation in logging handlers.
>
> {code}
> [standalone@localhost:9999 /] /subsystem=logging/console-handler=CONSOLE:read-resource
> {
> "outcome" => "success",
> "result" => {
> "autoflush" => true,
> "enabled" => true,
> ...
> }
> }
> {code}
> Calling disable() won't affect enabled attribute
> {code}
> [standalone@localhost:9999 /] /subsystem=logging/console-handler=CONSOLE:disable()
> {"outcome" => "success"}
> [standalone@localhost:9999 /] /subsystem=logging/console-handler=CONSOLE:read-resource
> {
> "outcome" => "success",
> "result" => {
> "autoflush" => true,
> "enabled" => true,
> ...
> }
> }
> {code}
> Must use write-attribute instead
> {code}
> [standalone@localhost:9999 /] /subsystem=logging/console-handler=CONSOLE/:write-attribute(name=enabled, value=false)
> {"outcome" => "success"}
> [standalone@localhost:9999 /] /subsystem=logging/console-handler=CONSOLE:read-resource
> {
> "outcome" => "success",
> "result" => {
> "autoflush" => true,
> "enabled" => false,
> ...
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] (AS7-6664) Unable to turn on/off logging handlers using enable()/disable() in CLI
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6664?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6664:
----------------------------------------------
Radim Hatlapatka <rhatlapa(a)redhat.com> made a comment on [bug 915317|https://bugzilla.redhat.com/show_bug.cgi?id=915317]
The issue is not fixed in EAP 6.1.0 ER3
> Unable to turn on/off logging handlers using enable()/disable() in CLI
> ----------------------------------------------------------------------
>
> Key: AS7-6664
> URL: https://issues.jboss.org/browse/AS7-6664
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management, Logging
> Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final)
> Reporter: Brian Stansberry
> Assignee: James Perkins
> Fix For: 8.0.0.Alpha1
>
>
> Peter Kremens reports:
> I am unable to use enable/disable operation in logging handlers.
>
> {code}
> [standalone@localhost:9999 /] /subsystem=logging/console-handler=CONSOLE:read-resource
> {
> "outcome" => "success",
> "result" => {
> "autoflush" => true,
> "enabled" => true,
> ...
> }
> }
> {code}
> Calling disable() won't affect enabled attribute
> {code}
> [standalone@localhost:9999 /] /subsystem=logging/console-handler=CONSOLE:disable()
> {"outcome" => "success"}
> [standalone@localhost:9999 /] /subsystem=logging/console-handler=CONSOLE:read-resource
> {
> "outcome" => "success",
> "result" => {
> "autoflush" => true,
> "enabled" => true,
> ...
> }
> }
> {code}
> Must use write-attribute instead
> {code}
> [standalone@localhost:9999 /] /subsystem=logging/console-handler=CONSOLE/:write-attribute(name=enabled, value=false)
> {"outcome" => "success"}
> [standalone@localhost:9999 /] /subsystem=logging/console-handler=CONSOLE:read-resource
> {
> "outcome" => "success",
> "result" => {
> "autoflush" => true,
> "enabled" => false,
> ...
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] (AS7-3884) Load testing application with Jmeter & jboss remoting throws exception saying "Too many channels open"
by Alexey S. (JIRA)
[ https://issues.jboss.org/browse/AS7-3884?page=com.atlassian.jira.plugin.s... ]
Alexey S. edited comment on AS7-3884 at 3/27/13 9:19 AM:
---------------------------------------------------------
...(comment added by mistake, sorry, we're still checking the situation)
was (Author: als):
Hello, Jaikiran, we got the same problem. The link that you gave for the hotfix jar is not active. When can we get the updated one?
> Load testing application with Jmeter & jboss remoting throws exception saying "Too many channels open"
> ------------------------------------------------------------------------------------------------------
>
> Key: AS7-3884
> URL: https://issues.jboss.org/browse/AS7-3884
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB, Naming
> Affects Versions: 7.1.0.Final
> Environment: windows 64 bit
> Reporter: Prasad Deshpande
> Assignee: jaikiran pai
> Fix For: 7.1.1.Final
>
> Attachments: logs.txt
>
>
> I've created a sampler for JMeter for load testing application. When I ran that with say around 30 threads with rampup time 80 seconds, after a while I kept getting exception specified in https://community.jboss.org/thread/195709?tstart=0. I later tried to close InitialContext in teardown methods, but wasn't really helpful. I looked at no. of InitialContext intances present in the VM using visualvm heapdump & found that just before throwing exception, it was 24 & after throwing exception for all threads, it did reach to 30, but it wasn't useful..
> Please note that, I'm creating InitialContext with passing following parameters to it:
> java.naming.factory.url.pkgs=org.jboss.ejb.client.naming
> java.naming.factory.initial=org.jboss.naming.remote.client.InitialContextFactory
> java.naming.provider.url=remote://localhost:4447
> jboss.naming.client.ejb.context=true
> Here is the code for Java Sampler
> {code}
> package com;
> import org.apache.jmeter.config.Arguments;
> import org.apache.jmeter.protocol.java.sampler.AbstractJavaSamplerClient;
> import org.apache.jmeter.protocol.java.sampler.JavaSamplerContext;
> import org.apache.jmeter.samplers.SampleResult;
> import com.banctec.caseware.client.api.API;
> import com.banctec.caseware.client.api.RemoteClientAPI;
> import com.banctec.caseware.resources.CaseResource;
> import com.banctec.caseware.resources.LoginResource;
> import com.banctec.caseware.resources.Resource;
> public class EJBTest extends AbstractJavaSamplerClient {
> private API api = null;
> private Long typeId;
> private int setupTestCalled = 0;
> private int teardownTestCalled = 0;
> private int runTestCalled = 0;
>
> public Arguments getDefaultParameters() {
> Arguments defaultParameters = new Arguments();
> defaultParameters.addArgument("typeId", "1");
> defaultParameters.addArgument("RunLoop", "200");
> defaultParameters.addArgument("username", "abc");
> defaultParameters.addArgument("password", "abc");
> return defaultParameters;
> }
>
> public void setupTest(JavaSamplerContext context) {
> try {
> typeId = context.getLongParameter("typeId");
> api = new RemoteClientAPI();//this is where InitialContext gets created
> LoginResource loginResource = new LoginResource(context.getParameter("username"), context.getParameter("password"));
> loginResource.setUseDefaultRole(Boolean.valueOf(true));
> api.login(new Resource[] { loginResource });
> }catch (Exception e) {
> e.printStackTrace();
> }
> System.out.println(" Number of times setupTest called "+(++setupTestCalled));
> }
>
> public void teardownTest(JavaSamplerContext context) {
> try{
> if (api != null) {
> api.logout();//In this method InitialContext.close() get's called
> }
> }catch (Exception e) {
> e.printStackTrace();
> }
> System.out.println(" Number of times teardownTest called "+(++teardownTestCalled));
> }
>
> public SampleResult runTest(JavaSamplerContext context) {
> SampleResult result = new SampleResult();
> boolean success = true;
> int loopCount = context.getIntParameter("RunLoop");
> result.sampleStart();
> //Here goes the code that will call few business methods on remote EJB's in application
> // I've purposely removed this bit here..
> System.out.println(" Number of times runTest called "+(++runTestCalled));
> result.sampleEnd();
> result.setSuccessful(success);
> return result;
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] (AS7-3884) Load testing application with Jmeter & jboss remoting throws exception saying "Too many channels open"
by Alexey S. (JIRA)
[ https://issues.jboss.org/browse/AS7-3884?page=com.atlassian.jira.plugin.s... ]
Alexey S. commented on AS7-3884:
--------------------------------
Hello, Jaikiran, we got the same problem. The link that you gave for the hotfix jar is not active. When can we get the updated one?
> Load testing application with Jmeter & jboss remoting throws exception saying "Too many channels open"
> ------------------------------------------------------------------------------------------------------
>
> Key: AS7-3884
> URL: https://issues.jboss.org/browse/AS7-3884
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB, Naming
> Affects Versions: 7.1.0.Final
> Environment: windows 64 bit
> Reporter: Prasad Deshpande
> Assignee: jaikiran pai
> Fix For: 7.1.1.Final
>
> Attachments: logs.txt
>
>
> I've created a sampler for JMeter for load testing application. When I ran that with say around 30 threads with rampup time 80 seconds, after a while I kept getting exception specified in https://community.jboss.org/thread/195709?tstart=0. I later tried to close InitialContext in teardown methods, but wasn't really helpful. I looked at no. of InitialContext intances present in the VM using visualvm heapdump & found that just before throwing exception, it was 24 & after throwing exception for all threads, it did reach to 30, but it wasn't useful..
> Please note that, I'm creating InitialContext with passing following parameters to it:
> java.naming.factory.url.pkgs=org.jboss.ejb.client.naming
> java.naming.factory.initial=org.jboss.naming.remote.client.InitialContextFactory
> java.naming.provider.url=remote://localhost:4447
> jboss.naming.client.ejb.context=true
> Here is the code for Java Sampler
> {code}
> package com;
> import org.apache.jmeter.config.Arguments;
> import org.apache.jmeter.protocol.java.sampler.AbstractJavaSamplerClient;
> import org.apache.jmeter.protocol.java.sampler.JavaSamplerContext;
> import org.apache.jmeter.samplers.SampleResult;
> import com.banctec.caseware.client.api.API;
> import com.banctec.caseware.client.api.RemoteClientAPI;
> import com.banctec.caseware.resources.CaseResource;
> import com.banctec.caseware.resources.LoginResource;
> import com.banctec.caseware.resources.Resource;
> public class EJBTest extends AbstractJavaSamplerClient {
> private API api = null;
> private Long typeId;
> private int setupTestCalled = 0;
> private int teardownTestCalled = 0;
> private int runTestCalled = 0;
>
> public Arguments getDefaultParameters() {
> Arguments defaultParameters = new Arguments();
> defaultParameters.addArgument("typeId", "1");
> defaultParameters.addArgument("RunLoop", "200");
> defaultParameters.addArgument("username", "abc");
> defaultParameters.addArgument("password", "abc");
> return defaultParameters;
> }
>
> public void setupTest(JavaSamplerContext context) {
> try {
> typeId = context.getLongParameter("typeId");
> api = new RemoteClientAPI();//this is where InitialContext gets created
> LoginResource loginResource = new LoginResource(context.getParameter("username"), context.getParameter("password"));
> loginResource.setUseDefaultRole(Boolean.valueOf(true));
> api.login(new Resource[] { loginResource });
> }catch (Exception e) {
> e.printStackTrace();
> }
> System.out.println(" Number of times setupTest called "+(++setupTestCalled));
> }
>
> public void teardownTest(JavaSamplerContext context) {
> try{
> if (api != null) {
> api.logout();//In this method InitialContext.close() get's called
> }
> }catch (Exception e) {
> e.printStackTrace();
> }
> System.out.println(" Number of times teardownTest called "+(++teardownTestCalled));
> }
>
> public SampleResult runTest(JavaSamplerContext context) {
> SampleResult result = new SampleResult();
> boolean success = true;
> int loopCount = context.getIntParameter("RunLoop");
> result.sampleStart();
> //Here goes the code that will call few business methods on remote EJB's in application
> // I've purposely removed this bit here..
> System.out.println(" Number of times runTest called "+(++runTestCalled));
> result.sampleEnd();
> result.setSuccessful(success);
> return result;
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] (AS7-6500) Wrong injection made by container
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6500?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6500:
----------------------------------------------
baranowb <bbaranow(a)redhat.com> made a comment on [bug 909914|https://bugzilla.redhat.com/show_bug.cgi?id=909914]
This should not be "NEW" issue.
> Wrong injection made by container
> ---------------------------------
>
> Key: AS7-6500
> URL: https://issues.jboss.org/browse/AS7-6500
> Project: Application Server 7
> Issue Type: Bug
> Components: EE, EJB, JPA / Hibernate
> Affects Versions: 7.1.2.Final (EAP), 7.1.3.Final (EAP), 7.1.4.Final (EAP)
> Reporter: Luan Cestari
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Alpha1
>
>
> Description of problem:
> I got an issue in a salesforce case [1] about an incorrect injection.
> [1] https://c.na7.visual.force.com/apex/Case_View?id=500A000000CRqDG&sfdc.ove...
> Version-Release number of selected component (if applicable):
> How reproducible:
> To reproduce the case is required to have two PersistentUnit (PU), a Abstract class with a setter method to inject one PU and others classes inheriting the Abstract class and overriding the setter method to inject a different PU. In the runtime, the container inject twice the PU, first the correct PU and then the PU described in super class.
> I talked with the client (who is a Red Hat consultant) and we made the attached project based on a very simple JBoss example to reproduce the issue which happens in EAP6. I put a lot of 'println' to be very clear (even printing stacktrace to show who is calling). The most important files are:
> -> hibernate4Test/src/main/java/org/jboss/as/quickstart/hibernate4/data/BaseDAO.java -- The abstract class with the default PU injection
> -> hibernate4Test/src/main/java/org/jboss/as/quickstart/hibernate4/data/MemberRepository.java -- BaseDAO subclass
> -> hibernate4Test/src/main/java/org/jboss/as/quickstart/hibernate4/data/SecondaryMemberRepository.java -- BaseDAO subclass
> -> hibernate4Test/src/main/java/org/jboss/as/quickstart/hibernate4/data/MemberListProducer.java -- The class which inject the MemberListProducer and SecondaryMemberRepository
> -> hibernate4Test/src/main/resources/META-INF/persistence.xml -- We changed the configuration here to each PU have a different entity mapped
> Steps to Reproduce:
>
> Actual results:
> The EM injection occurs twice, which the last one the wrong EM.
> Expected results:
> Just one injection occurs.
> Additional info:
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months