[JBoss JIRA] (ELY-88) Command line utilities
by Peter Skopek (JIRA)
[ https://issues.jboss.org/browse/ELY-88?page=com.atlassian.jira.plugin.sys... ]
Peter Skopek reassigned ELY-88:
-------------------------------
Assignee: Peter Skopek
> Command line utilities
> ----------------------
>
> Key: ELY-88
> URL: https://issues.jboss.org/browse/ELY-88
> Project: WildFly Elytron
> Issue Type: Feature Request
> Reporter: David Lloyd
> Assignee: Peter Skopek
> Fix For: 1.1.0.Beta1
>
>
> We should provide easy-to-use command line tools from the Elytron JAR as a main class that provide useful functions to users like:
> * Creating password hashes
> * Creating certificates and certificate requests
> * Creating key pairs of various types
> * Managing key stores (everything keytool does)
> * Get the library version
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (JBJCA-1290) WildFly 10 + Hibernate 5 + Spring 4.2 + JTA stack results in ResourceException
by Tomas Repel (JIRA)
Tomas Repel created JBJCA-1290:
----------------------------------
Summary: WildFly 10 + Hibernate 5 + Spring 4.2 + JTA stack results in ResourceException
Key: JBJCA-1290
URL: https://issues.jboss.org/browse/JBJCA-1290
Project: IronJacamar
Issue Type: Bug
Affects Versions: 1.2.5.Final
Reporter: Tomas Repel
Assignee: Jesper Pedersen
I have EAR with simple non-JPA Hibernate based domain and dao submodules and web submodule. I want to use JTA and container managed transactions. When deploying on WildFly 9 (using Hibernate4) everything works fine. I migrated the app to WildFly 10 (using Hibernate5) but after several clicks in browser an exception is thrown:
{code}
...
Caused by: javax.resource.ResourceException: IJ000453: Unable to get managed connection for java:jboss/datasources/ExampleDS
at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:646)
at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:430)
at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:737)
at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:138)
... 43 more
Caused by: javax.resource.ResourceException: IJ000655: No managed connections available within configured blocking timeout (30000 [ms])
at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:569)
at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:627)
at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:599)
at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:579)
... 46 more
{code}
I have created simple reproducer on github, see https://github.com/trepel/primrose-hibernate-simple
There is also Stack Overflow question, see
http://stackoverflow.com/questions/32114110/wildfly-10-hibernate-5-spring...
It was suggested that this might be related to IronJacamar.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (DROOLS-37) Operators on java.lang.Comparable object doesn't work if JIT is enable
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-37?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on DROOLS-37:
-----------------------------------------------
Ryan Zhang <rzhang(a)redhat.com> changed the Status of [bug 1233978|https://bugzilla.redhat.com/show_bug.cgi?id=1233978] from MODIFIED to ON_QA
> Operators on java.lang.Comparable object doesn't work if JIT is enable
> ----------------------------------------------------------------------
>
> Key: DROOLS-37
> URL: https://issues.jboss.org/browse/DROOLS-37
> Project: Drools
> Issue Type: Bug
> Affects Versions: 5.5.0.Final
> Environment: Windows XP
> Java 1.5
> joda-time 1.6.2
> Reporter: Jérémy SOULA
> Assignee: Mario Fusco
> Labels: 5.5, comparable, localDate
> Fix For: 5.5.1.Final, 6.0.0.Alpha9
>
> Attachments: drools-bugs.zip
>
>
> In my application, i have rules that used org.joda.time.LocalDate to compare date like
> {noformat}
> rule "toto"
> when
> LocalDateForDroolsTestBean(
> infDate>=supDate
> )
> then
> //Anything
> end
> {noformat}
> With Drools 5.3, all works fine.
> With Drools 5.5, an exception occured because JIT optimizer automaticaly enabled:
> {noformat}
> Exception in thread "main" java.lang.NoSuchMethodError: org.joda.time.LocalDate.compareTo(Lorg/joda/time/LocalDate;)I
> at ConditionEvaluatorf8ba8fa3003345adbf3979e901488f23.evaluate(Unknown Source)
> at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:200)
> at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:157)
> at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:137)
> at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
> at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235)
> at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311)
> at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903)
> at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847)
> at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)
> at org.drools.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:304)
> at fr.jsoula.jboss.drools.bugs.comparable.ComparableBug.main(ComparableBug.java:39)
> {noformat}
> After search, it seems that the bytecode generated by org.drools.rule.builder.dialect.asm.ClassGenerator can't call the method public int compareTo(Object partial) of org.joda.time.LocalDate. The parameter of the method must be the same class of the current object.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (DROOLS-795) Timers are reset during the serialization process
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-795?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-795:
------------------------------------------------
Ryan Zhang <rzhang(a)redhat.com> changed the Status of [bug 1248429|https://bugzilla.redhat.com/show_bug.cgi?id=1248429] from MODIFIED to ON_QA
> Timers are reset during the serialization process
> -------------------------------------------------
>
> Key: DROOLS-795
> URL: https://issues.jboss.org/browse/DROOLS-795
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 6.3.0.CR1
>
>
> When the marshall serializes a timer it doesn't take count of how much time it is already passed, so when the timer is deserialized it restart from it start time. The following failing test case reproduces the problem.
> {code}
> @Test
> public void testMarshallWithTimedRule() {
> String drl = "rule \"Rule A Timeout\"\n" +
> "when\n" +
> " String( this == \"ATrigger\" )\n" +
> "then\n" +
> " insert (new String( \"A-Timer\") );\n" +
> "System.out.println(\"+++++++Got ATrigger, started A-Timer with 5s timeout\");\n" +
> "end\n" +
> "\n" +
> "rule \"Timer For rule A Timeout\"\n" +
> " timer ( int: 5s )\n" +
> "when\n" +
> " String( this == \"A-Timer\")\n" +
> "then\n" +
> " delete ( \"A-Timer\" );\n" +
> " delete ( \"ATrigger\" );\n" +
> "System.out.println(\"******* reset rule A based on timer\");\n" +
> "end\n";
> KieBase kbase = new KieHelper().addContent( drl, ResourceType.DRL )
> .build( EqualityBehaviorOption.EQUALITY,
> DeclarativeAgendaOption.ENABLED,
> EventProcessingOption.STREAM );
> KieSessionConfiguration sessionConfig = KnowledgeBaseFactory.newKnowledgeSessionConfiguration();
> sessionConfig.setOption( ClockTypeOption.get( "pseudo" ) );
> KieSession ksession = kbase.newKieSession(sessionConfig, null);
> ksession.insert( new String( "ATrigger" ) );
> assertEquals( 1, ksession.getFactCount() );
> ksession.fireAllRules();
> assertEquals( 2, ksession.getFactCount() );
> SessionPseudoClock clock = ksession.getSessionClock();
> clock.advanceTime( 4, TimeUnit.SECONDS );
> assertEquals( 2, ksession.getFactCount() );
> ksession.fireAllRules();
> assertEquals( 2, ksession.getFactCount() );
> ksession = marshallAndUnmarshall( kbase, ksession, sessionConfig);
> clock = ksession.getSessionClock();
> clock.advanceTime( 4, TimeUnit.SECONDS );
> assertEquals( 2, ksession.getFactCount() );
> ksession.fireAllRules();
> assertEquals( 0, ksession.getFactCount() );
> }
> public static KieSession marshallAndUnmarshall(KieBase kbase, KieSession ksession, KieSessionConfiguration sessionConfig) {
> // Serialize and Deserialize
> try {
> Marshaller marshaller = KieServices.Factory.get().getMarshallers().newMarshaller(kbase);
> ByteArrayOutputStream baos = new ByteArrayOutputStream();
> marshaller.marshall(baos, ksession);
> marshaller = MarshallerFactory.newMarshaller( kbase );
> ByteArrayInputStream bais = new ByteArrayInputStream(baos.toByteArray());
> baos.close();
> ksession = marshaller.unmarshall(bais, sessionConfig, null);
> bais.close();
> } catch (Exception e) {
> e.printStackTrace();
> fail("unexpected exception :" + e.getMessage());
> }
> return ksession;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFCORE-736) Memory leak in server management controller
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-736?page=com.atlassian.jira.plugin... ]
Petr Kremensky commented on WFCORE-736:
---------------------------------------
I re-opened the JBEAP-283, assuming this one should be also re-opened.
> Memory leak in server management controller
> -------------------------------------------
>
> Key: WFCORE-736
> URL: https://issues.jboss.org/browse/WFCORE-736
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Remoting
> Reporter: Sergey Lisovoy
> Assignee: David Lloyd
> Labels: memory_leak, memoryleak, remoting
> Fix For: 2.0.0.Beta5
>
> Attachments: screenshot-1.png
>
>
> I have a simple thread that monitor remote wildfly process status. After some time client fails. Wildfly server also eat all memory and reports about connection errors. Some times wildfly also fails with fails with OutOfMemory exception.
> Client code:
> {code:java}
> package ru.kamis.tests.xniomemoryleaks;
> import org.jboss.as.controller.client.ModelControllerClient;
> import org.jboss.as.controller.client.helpers.Operations;
> import org.jboss.dmr.ModelNode;
> public class OutOfMemoryDemo {
> public static void main(String[] args) throws Exception {
>
> for(int i=0; i<1000000; i++) {
> ModelControllerClient client = null;
> client = ModelControllerClient.Factory.create("localhost", 9990);
>
> ModelNode operation = Operations.createReadAttributeOperation(new ModelNode().setEmptyList(), "server-state");
> client.execute(operation);
>
> client.close();
>
> if(i % 1000 == 0) {
> System.out.println("Processed: " + i);
> }
> }
> }
> }
> {code}
> Client output:
> {noformat}
> июн 05, 2015 11:21:51 AM org.xnio.Xnio <clinit>
> INFO: XNIO version 3.2.0.Final
> июн 05, 2015 11:21:51 AM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.3.0.Final
> июн 05, 2015 11:21:51 AM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 4.0.6.Final
> Processed: 0
> Processed: 1000
> Processed: 2000
> Processed: 3000
> Processed: 4000
> Processed: 5000
> Exception in thread "main" java.io.IOException: java.net.ConnectException: JBAS012144: Could not connect to http-remoting://localhost:9990. The connection timed out
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> at ru.kamis.tests.xniomemoryleaks.OutOfMemoryDemo.main(OutOfMemoryDemo.java:12)
> Caused by: java.net.ConnectException: JBAS012144: Could not connect to http-remoting://localhost:9990. The connection timed out
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:119)
> at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
> at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
> at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:148)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:67)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> ... 2 more
> {noformat}
> Client libraries:
> {code:xml}
> <dependency>
> <groupId>org.wildfly</groupId>
> <artifactId>wildfly-controller-client</artifactId>
> <version>8.2.0.Final</version>
> </dependency>
> <dependency>
> <groupId>org.jboss.remoting</groupId>
> <artifactId>jboss-remoting</artifactId>
> <version>4.0.6.Final</version>
> </dependency>
> {code}
> Project to reproduce error:
> [https://github.com/lis0x90/jboss-remoting-momory-leak-reproduce]
> Wildfly logs:
> {noformat}
> ...
> 2015-06-05 11:21:10,195 DEBUG [org.jboss.as.config] (MSC service thread 1-6) VM Arguments: -Dprogram.name=standalone.bat -Xms64M -Xmx512M -XX:MaxPermSize=256M -Djboss.remoting.leakdebugging=true -Duser.country=RU -Duser.language=en -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Dorg.jboss.boot.log.file=H:\java\wildfly-8.2.0.Final\standalone\log\server.log -Dlogging.configuration=file:H:\java\wildfly-8.2.0.Final\standalone\configuration/logging.properties
> ...
> 2015-06-05 11:21:11,923 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.2.0.Final "Tweek" started in 2259ms - Started 194 of 246 services (86 services are lazy, passive or on-demand)
> 2015-06-05 11:22:51,726 ERROR [org.jboss.remoting.remote.connection] (XNIO-1 I/O-2) JBREM000200: Remote connection failed: java.io.IOException: Программа на вашем хост-компьютере разорвала установленное подключение
> 2015-06-05 11:23:59,306 ERROR [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) JBREM000200: Remote connection failed: java.io.IOException: Программа на вашем хост-компьютере разорвала установленное подключение
> 2015-06-05 11:24:02,527 ERROR [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) JBREM000200: Remote connection failed: java.io.IOException: Программа на вашем хост-компьютере разорвала установленное подключение
> 2015-06-05 11:24:16,142 ERROR [org.jboss.remoting.remote.connection] (XNIO-1 I/O-2) JBREM000200: Remote connection failed: java.io.IOException: Программа на вашем хост-компьютере разорвала установленное подключение
> 2015-06-05 11:24:21,312 ERROR [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) JBREM000200: Remote connection failed: java.io.IOException: Программа на вашем хост-компьютере разорвала установленное подключение
> 2015-06-05 11:24:27,458 ERROR [org.jboss.remoting.remote.connection] (XNIO-1 I/O-2) JBREM000200: Remote connection failed: java.io.IOException: Программа на вашем хост-компьютере разорвала установленное подключение
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFLY-5205) Intermittent ServletException when handling request - Deployment has stopped
by Michal Vinkler (JIRA)
Michal Vinkler created WFLY-5205:
------------------------------------
Summary: Intermittent ServletException when handling request - Deployment has stopped
Key: WFLY-5205
URL: https://issues.jboss.org/browse/WFLY-5205
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Reporter: Michal Vinkler
Assignee: Stuart Douglas
Priority: Minor
Setup: 4-node cluster, one node at time undeploys application (clusterbench-ee7.ear), while standalone clients keep calling the application.
This error was seen during clustering failover testing in the following scenario:
ejb-ejbservlet-repl-sync (failover of HTTP traffic accessing a servlet that locally invokes a stateful clustered EJB, with synchronously replicated cache)
After undeploying application on perf19 (second node in the cluster), this error message was logged 17 times in the server log:
{code}
[JBossINF] [0m[31m20:01:42,682 ERROR [io.undertow.request] (default task-107) UT005023: Exception handling request to /clusterbench/ejbservlet: javax.servlet.ServletException: UT010051: Deployment clusterbench-ee7.ear.clusterbench-ee7-web-default.war has stopped
[JBossINF] at io.undertow.servlet.core.ManagedServlet.getServlet(ManagedServlet.java:165)
[JBossINF] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
[JBossINF] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
[JBossINF] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
[JBossINF] at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
[JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
[JBossINF] at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
[JBossINF] at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
[JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
[JBossINF] at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
[JBossINF] at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
[JBossINF] at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
[JBossINF] at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
[JBossINF] at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
[JBossINF] at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
[JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
[JBossINF] at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
[JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
[JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
[JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
[JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
[JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
[JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
[JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
[JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:778)
[JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[JBossINF] at java.lang.Thread.run(Thread.java:745)
{code}
Other nodes in the cluster did not get the error.
Server log:
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFLY-5205) Intermittent ServletException when handling request - Deployment has stopped
by Michal Vinkler (JIRA)
[ https://issues.jboss.org/browse/WFLY-5205?page=com.atlassian.jira.plugin.... ]
Michal Vinkler updated WFLY-5205:
---------------------------------
Affects Version/s: 10.0.0.Beta1
> Intermittent ServletException when handling request - Deployment has stopped
> ----------------------------------------------------------------------------
>
> Key: WFLY-5205
> URL: https://issues.jboss.org/browse/WFLY-5205
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Beta1
> Reporter: Michal Vinkler
> Assignee: Stuart Douglas
> Priority: Minor
>
> Setup: 4-node cluster, one node at time undeploys application (clusterbench-ee7.ear), while standalone clients keep calling the application.
> This error was seen during clustering failover testing in the following scenario:
> ejb-ejbservlet-repl-sync (failover of HTTP traffic accessing a servlet that locally invokes a stateful clustered EJB, with synchronously replicated cache)
> After undeploying application on perf19 (second node in the cluster), this error message was logged 17 times in the server log:
> {code}
> [JBossINF] [0m[31m20:01:42,682 ERROR [io.undertow.request] (default task-107) UT005023: Exception handling request to /clusterbench/ejbservlet: javax.servlet.ServletException: UT010051: Deployment clusterbench-ee7.ear.clusterbench-ee7-web-default.war has stopped
> [JBossINF] at io.undertow.servlet.core.ManagedServlet.getServlet(ManagedServlet.java:165)
> [JBossINF] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> [JBossINF] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> [JBossINF] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> [JBossINF] at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> [JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> [JBossINF] at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> [JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> [JBossINF] at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> [JBossINF] at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> [JBossINF] at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
> [JBossINF] at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> [JBossINF] at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> [JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> [JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> [JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> [JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:778)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> {code}
> Other nodes in the cluster did not get the error.
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months
[JBoss JIRA] (WFCORE-855) Intermittent Disconnection from CLI After Reload in domain mode
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-855?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-855:
------------------------------------------------
Carlo de Wolf <cdewolf(a)redhat.com> changed the Status of [bug 1249031|https://bugzilla.redhat.com/show_bug.cgi?id=1249031] from POST to MODIFIED
> Intermittent Disconnection from CLI After Reload in domain mode
> ---------------------------------------------------------------
>
> Key: WFCORE-855
> URL: https://issues.jboss.org/browse/WFCORE-855
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.0.Alpha12
> Reporter: Joe Wertz
> Assignee: Joe Wertz
> Fix For: 2.0.0.Alpha13
>
> Original Estimate: 3 minutes
> Time Spent: 3 hours
> Remaining Estimate: 0 minutes
>
> Description of problem:
> CLI scripts for management of managed domain
> Version-Release number of selected component (if applicable):
> 6.4.3.CP.CR1
> How reproducible:
> Always
> Steps to Reproduce:
> Use CLI script:
> :read-attribute(name=process-type)
> reload --host=master
> :read-attribute(name=process-type)
> or commands option for script
> Actual results:
> 6.4.3
> ./jboss-cli.sh -c commands=':read-attribute(name=process-type), reload --host=master, :read-attribute(name=process-type)'
> {
> "outcome" => "success",
> "result" => "Domain Controller"
> }
> Failed to establish connection in 6025ms
> Expected results:
> 6.3.3
> ./jboss-cli.sh -c commands=':read-attribute(name=process-type), reload --host=master, :read-attribute(name=process-type)'
> {
> "outcome" => "success",
> "result" => "Domain Controller"
> }
> {
> "outcome" => "success",
> "result" => "Domain Controller"
> }
> Additional info:
> - Follow up to https://bugzilla.redhat.com/show_bug.cgi?id=1232933
> - using --timeout doesn't workaround the problem
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 2 months