[JBoss JIRA] (AS7-3973) Yet another place where hardcoded IPv4 address scheme is used
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/AS7-3973?page=com.atlassian.jira.plugin.s... ]
Ondrej Zizka resolved AS7-3973.
-------------------------------
Fix Version/s: 7.1.1.Final
Resolution: Done
I see no failure in this either. Resolving, pls reopen in case.
> Yet another place where hardcoded IPv4 address scheme is used
> -------------------------------------------------------------
>
> Key: AS7-3973
> URL: https://issues.jboss.org/browse/AS7-3973
> Project: Application Server 7
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 7.1.1.Final
> Reporter: Pavel Janousek
> Assignee: Ondrej Zizka
> Priority: Blocker
> Fix For: 7.1.1.Final
>
>
> After the last Stuart commit and merge to upstream (on -Thursday- Wednesday morning CET time zone), there are still some places where hardcoded IPv4 address scheme is used.
> Wrong TestCases are:
> - org.jboss.as.test.integration.ejb.security.callerprincipal.GetCallerPrincipalTestCase
> - org.jboss.as.test.integration.ejb.mdb.containerstart.SendMessagesTestCase
> Both of them use 127.0.0.1 directly even -Dnode0=::1 - it seems to be some other magic inside them because [there|http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-t...] TS passed, but I also reconfigure my machine to avoid IPv4 name address translation like:
> {code}
> #127.0.0.1 localhost.localdomain
> #127.0.0.1 pjanouse.brq.redhat.com localhost
> ::1 localhost6.localdomain6 localhost6 localhost
> ::1 pjanouse.brq.redhat.com localhost
> 127.0.0.2 both
> ::2 both
> 2001:0000:1234:0000:0000:c1c0:abcd:0876 ip6
> {code}
> I've got this result:{code}
> Tests in error:
> org.jboss.as.test.integration.ejb.security.callerprincipal.GetCallerPrincipalTestCase: java.net.ConnectException: JBAS012144: Could not connect to remote://127.0.0.1:9999. The connection timed out
> org.jboss.as.test.integration.ejb.security.callerprincipal.GetCallerPrincipalTestCase: java.net.ConnectException: JBAS012144: Could not connect to remote://127.0.0.1:9999. The connection timed out
> org.jboss.as.test.integration.ejb.mdb.containerstart.SendMessagesTestCase: java.net.ConnectException: JBAS012144: Could not connect to remote://127.0.0.1:9999. The connection timed out
> org.jboss.as.test.integration.ejb.mdb.containerstart.SendMessagesTestCase: java.net.ConnectException: JBAS012144: Could not connect to remote://127.0.0.1:9999. The connection timed out
> {code}
> It seems there are several other problems in clustering and domain, but I'll report them after deeper investigation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-4028) Creating new Periodic File Rotating Handler allows to enter a wrong suffix in domain mode
by Pavel Slegr (JIRA)
Pavel Slegr created AS7-4028:
--------------------------------
Summary: Creating new Periodic File Rotating Handler allows to enter a wrong suffix in domain mode
Key: AS7-4028
URL: https://issues.jboss.org/browse/AS7-4028
Project: Application Server 7
Issue Type: Bug
Components: Logging
Affects Versions: 7.1.0.Final
Reporter: Pavel Slegr
Assignee: James Perkins
Fix For: 7.1.2.Final
While running server in domain mode, It is possible to create new Periodic File Rotating Handler with suffix "s" , and the same approach in standalone mode correctly throws (via Admin Console)
Caused by: java.lang.IllegalArgumentException: Rotating by second or millisecond is not supported
at org.jboss.logmanager.handlers.PeriodicRotatingFileHandler.setSuffix(PeriodicRotatingFileHandler.java:141) [jboss-logmanager-1.2.2.GA.jar:1.2.2.GA]
or in CLI
[standalone@localhost:9999 periodic-rotating-file-handler=testx] :write-attribute(name=suffix, value="ss")
{
"outcome" => "failed",
"failure-description" => "JBAS014749: Operation handler failed: Rotating by second or millisecond is not supported",
"rolled-back" => true
}
In domain mode:
[domain@localhost:9999 periodic-rotating-file-handler=test4] :write-attribute(name=suffix, value="ss")
{
"outcome" => "success",
"result" => undefined,
"server-groups" => undefined
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-3884) Load testing application with Jmeter & jboss remoting throws exception saying "Too many channels open"
by Prasad Deshpande (JIRA)
[ https://issues.jboss.org/browse/AS7-3884?page=com.atlassian.jira.plugin.s... ]
Prasad Deshpande updated AS7-3884:
----------------------------------
Attachment: logs.txt
I'm still getting few errors, not sure if that's related to application.. didn't analyse logs myself yet.. just attached them for your reference..
> 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: John Bailey
> 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: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-2342) Multiple Log Directories in one tree
by Jim Tyrrell (Created) (JIRA)
Multiple Log Directories in one tree
------------------------------------
Key: AS7-2342
URL: https://issues.jboss.org/browse/AS7-2342
Project: Application Server 7
Issue Type: Feature Request
Reporter: Jim Tyrrell
See the attached screen shot, does it make sense to have the log files in each of the server/s directories, along with the log directory in the domain context. When first looking for log files, it was odd to cd to domain, and then cd to log and not see my server directories. For a long time JBoss user what we are doing does not probably hurt that much, but for a new user, having multiple log directories is a little odd. Does it make sense to have just one log directory. In this case:
domain/log/server-one
domain/log/server-two
...
instead of
domina/log
domain/servers/server-one/log
domain/servers/server-two/log
...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month