[JBoss JIRA] (AS7-5373) NPE on undeployment of cdi-injection quickstart
by Kabir Khan (JIRA)
Kabir Khan created AS7-5373:
-------------------------------
Summary: NPE on undeployment of cdi-injection quickstart
Key: AS7-5373
URL: https://issues.jboss.org/browse/AS7-5373
Project: Application Server 7
Issue Type: Bug
Components: JSF
Reporter: Kabir Khan
Assignee: Stan Silvert
Fix For: 7.1.3.Final (EAP)
Running the quickstarts against the 7.1 branch as shown in http://www.jboss.org/jdf/about/contributing/:
{code}
mvn clean install jboss-as:deploy jboss-as:undeploy -Parq-jbossas-remote -P-requires-postgres,-requires-full,-complex-dependencies,-requires-xts -pl cdi-injection/
{code}
I notice a few occurrences of the following error on undeployment, cdi-injection is just singled out since it is the first place this occurs.
{code}
23:25:46,983 INFO [org.jboss.web] (MSC service thread 1-7) JBAS018210: Registering web context: /jboss-as-cdi-injection
23:25:46,991 INFO [org.jboss.as.server] (management-handler-thread - 1) JBAS018559: Deployed "jboss-as-cdi-injection.war"
23:25:47,022 INFO [org.jboss.as.osgi] (MSC service thread 1-3) JBAS011908: Unregister module: Module "deployment.jboss-as-cdi-injection.war:main" from Service Module Loader
23:30:06,207 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-5) Unexpected exception when attempting to tear down the Mojarra runtime: java.lang.NullPointerException
at javax.faces.component.UIViewRoot.setLocale(UIViewRoot.java:1463) [jboss-jsf-api_2.1_spec-2.0.4.Final.jar:2.0.4.Final]
at com.sun.faces.config.InitFacesContext.getViewRoot(InitFacesContext.java:213) [jsf-impl-2.1.11-jbossorg-2.jar:]
at com.sun.faces.application.ApplicationImpl.invokeViewListenersFor(ApplicationImpl.java:2026) [jsf-impl-2.1.11-jbossorg-2.jar:]
at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:291) [jsf-impl-2.1.11-jbossorg-2.jar:]
at org.jboss.as.weld.webtier.jsf.ForwardingApplication.publishEvent(ForwardingApplication.java:288) [jboss-as-weld-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at com.sun.faces.config.ConfigureListener.contextDestroyed(ConfigureListener.java:335) [jsf-impl-2.1.11-jbossorg-2.jar:]
at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:3489) [jbossweb-7.0.17.Final.jar:]
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:3999) [jbossweb-7.0.17.Final.jar:]
at org.jboss.as.web.deployment.WebDeploymentService.stop(WebDeploymentService.java:107) [jboss-as-web-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1911)
at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1874)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [classes.jar:1.6.0_33]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [classes.jar:1.6.0_33]
at java.lang.Thread.run(Thread.java:680) [classes.jar:1.6.0_33]
23:30:06,221 INFO [org.jboss.weld.deployer] (MSC service thread 1-13) JBAS016009: Stopping weld service for deployment jboss-as-cdi-injection.war
23:30:06,237 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment jboss-as-cdi-injection.war in 259217ms
23:30:06,245 INFO [org.jboss.as.repository] (management-handler-thread - 5) JBAS014901: Content removed from location /Users/kabir/sourcecontrol/jboss-as7/git/jboss-as/build/target/jboss-as-7.1.3.Final-SNAPSHOT/standalone/data/content/78/15373bb6bb12630f25faef010adf9a328e4761/content
23:30:06,245 INFO [org.jboss.as.server] (management-handler-thread - 5) JBAS018558: Undeployed "jboss-as-cdi-injection.war"
{code}
The code in UIViewRoot is
{code}
FacesContext.getCurrentInstance().getELContext().setLocale(locale);
{code}
Stepping through with a debugger shows that the current instance is null
--
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
12 years, 2 months
[JBoss JIRA] Created: (AS7-1371) Domain Management - Support for database connection pool in non AS process.
by Darran Lofthouse (JIRA)
Domain Management - Support for database connection pool in non AS process.
---------------------------------------------------------------------------
Key: AS7-1371
URL: https://issues.jboss.org/browse/AS7-1371
Project: Application Server 7
Issue Type: Task
Components: Domain Management
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 7.1.0.Beta1
We need to support authentication for users stored in database, the domain management is in a non-AS process so we also need a pool of database connections.
These connections will be used to read only from the database, other than the isolation offered by the driver we should not require any advanced transaction support.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (AS7-5140) Support binding of URL resources
by Akram Ben Aissi (JIRA)
Akram Ben Aissi created AS7-5140:
------------------------------------
Summary: Support binding of URL resources
Key: AS7-5140
URL: https://issues.jboss.org/browse/AS7-5140
Project: Application Server 7
Issue Type: Feature Request
Components: Naming
Affects Versions: 7.1.2.Final (EAP), 7.1.1.Final
Reporter: Akram Ben Aissi
Assignee: John Bailey
Priority: Critical
Binding of a resource of type java.net.URL is not available out of the box.
This is a common requirement in many environment.
This could be achieved either by providing a simple-type "url" (like int, string, etc...) that uses the String constructor of URL class.
Or one could provide an object-factory that build URL, but this requires to pass parameters on it.
--
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
12 years, 2 months
[JBoss JIRA] (AS7-3055) RESTEasy: Empty cfg. param javax.ws.rs.Application produces exception
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-3055?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry commented on AS7-3055:
---------------------------------------
I just "Rejected" the linked pull request, not because I have an opinion on the pull request, but because it's not an AS7 pull request. So this JIRA should not be in status "Pull Request Sent". Is there an associated JIRA in https://issues.jboss.org/browse/RESTEasy?
> RESTEasy: Empty cfg. param javax.ws.rs.Application produces exception
> ---------------------------------------------------------------------
>
> Key: AS7-3055
> URL: https://issues.jboss.org/browse/AS7-3055
> Project: Application Server 7
> Issue Type: Bug
> Components: REST
> Affects Versions: 7.1.0.Beta1b
> Reporter: Pavel Janousek
> Assignee: Weinan Li
>
> RESTEasy can be configured through several configuration options in WAR application deployment file WEB-INF/web.xml. The major one (also portable defined by JAX-RS standard) is _javax.ws.rs.Application_. When I set this parameter to empty content present behavior is raising exception "java.lang.StringIndexOutOfBoundsException: String index out of range: 0", it is not so good.
> I think, this is hard miss-configuration error and deployment description as this one should be rejected and a such application should not be deployed at all with appropriate error message, but not only by messed exception.
--
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
12 years, 2 months
[JBoss JIRA] (AS7-5379) CLONE - Stale data received with SYNC on failover
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-5379?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-5379:
----------------------------------
Priority: Blocker (was: Critical)
> CLONE - Stale data received with SYNC on failover
> -------------------------------------------------
>
> Key: AS7-5379
> URL: https://issues.jboss.org/browse/AS7-5379
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Environment: affected 6.0.0 DR CI build
> Reporter: Radoslav Husar
> Assignee: Paul Ferraro
> Priority: Blocker
> Labels: as713tracking
> Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1
>
>
> After verifying fix for JBPAPP-8937 I am instead seeing stale data received when using DIST SYNC replication.
> REPL SYNC: On a failover after the application has been gracefully undeployed, a request can be getting data older by cca 40 seconds:
> {noformat}
> 2012/08/14 15:12:53:327 EDT [WARN ][Runner - 1295] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 46, received 35, Runner: 1295>
> org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 46, received 35, Runner: 1295
> at org.jboss.smartfrog.loaddriver.http.AbstractSerialNumberValidatorFactoryImpl$SerialNumberValidator.processRequest(AbstractSerialNumberValidatorFactoryImpl.java:125)
> at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
> at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
> at java.lang.Thread.run(Thread.java:662)
> {noformat}
> DIST SYNC: On server crash stale data can be received:
> {noformat}
> 2012/08/04 05:13:49:714 EDT [WARN ][Runner - 8] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 43, received 42, Runner: 8>
> org.jboss.smartfrog.loaddriver.RequestProcessingException: Stale session data received. Expected 43, received 42, Runner: 8
> at org.jboss.smartfrog.loaddriver.http.AbstractSerialNumberValidatorFactoryImpl$SerialNumberValidator.processRequest(AbstractSerialNumberValidatorFactoryImpl.java:125)
> at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
> at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
> at java.lang.Thread.run(Thread.java:662)
> {noformat}
--
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
12 years, 2 months
[JBoss JIRA] (AS7-4143) Failover scenarios often fail with "StateTransferInProgressException: Timed out waiting for the state transfer lock, state transfer in progress for view Y"
by Radoslav Husar (JIRA)
Radoslav Husar created AS7-4143:
-----------------------------------
Summary: Failover scenarios often fail with "StateTransferInProgressException: Timed out waiting for the state transfer lock, state transfer in progress for view Y"
Key: AS7-4143
URL: https://issues.jboss.org/browse/AS7-4143
Project: Application Server 7
Issue Type: Bug
Components: Clustering
Affects Versions: 7.1.1.Final
Environment: Linux
Reporter: Radoslav Husar
Assignee: Paul Ferraro
Priority: Critical
Fix For: 7.1.2.Final
Most of the positive failover scenarios under little load result in StateTransferInProgressException.
Load is on average 50r/s (which is 200x less than AS5 easily handles).
{noformat}
[JBossINF] 16:04:42,099 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (ajp-perf20-10.16.90.58-8009-25) ISPN000136: Execution error: org.infinispan.statetransfer.StateTransferInProgressException: Timed out waiting for the state transfer lock, state transfer in progress for view 23
[JBossINF] at org.infinispan.interceptors.StateTransferLockInterceptor.signalStateTransferInProgress(StateTransferLockInterceptor.java:199) [infinispan-core-5.1.2.FINAL-redhat-1.jar:5.1.2.FINAL-redhat-1]
[JBossINF] at org.infinispan.interceptors.StateTransferLockInterceptor.visitPrepareCommand(StateTransferLockInterceptor.java:80) [infinispan-core-5.1.2.FINAL-redhat-1.jar:5.1.2.FINAL-redhat-1]
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:131) [infinispan-core-5.1.2.FINAL-redhat-1.jar:5.1.2.FINAL-redhat-1]
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) [infinispan-core-5.1.2.FINAL-redhat-1.jar:5.1.2.FINAL-redhat-1]
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130) [infinispan-core-5.1.2.FINAL-redhat-1.jar:5.1.2.FINAL-redhat-1]
[JBossINF] at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:113) [infinispan-core-5.1.2.FINAL-redhat-1.jar:5.1.2.FINAL-redhat-1]
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:131) [infinispan-core-5.1.2.FINAL-redhat-1.jar:5.1.2.FINAL-redhat-1]
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) [infinispan-core-5.1.2.FINAL-redhat-1.jar:5.1.2.FINAL-redhat-1]
[JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:130) [infinispan-core-5.1.2.FINAL-redhat-1.jar:5.1.2.FINAL-redhat-1]
[JBossINF] at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:89) [infinispan-core-5.1.2.FINAL-redhat-1.jar:5.1.2.FINAL-redhat-1]
[JBossINF] at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:113) [infinispan-core-5.1.2.FINAL-redhat-1.jar:5.1.2.FINAL-redhat-1]
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:131) [infinispan-core-5.1.2.FINAL-redhat-1.jar:5.1.2.FINAL-redhat-1]
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) [infinispan-core-5.1.2.FINAL-redhat-1.jar:5.1.2.FINAL-redhat-1]
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130) [infinispan-core-5.1.2.FINAL-redhat-1.jar:5.1.2.FINAL-redhat-1]
[JBossINF] at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:113) [infinispan-core-5.1.2.FINAL-redhat-1.jar:5.1.2.FINAL-redhat-1]
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:131) [infinispan-core-5.1.2.FINAL-redhat-1.jar:5.1.2.FINAL-redhat-1]
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) [infinispan-core-5.1.2.FINAL-redhat-1.jar:5.1.2.FINAL-redhat-1]
[JBossINF] at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:86) [infinispan-core-5.1.2.FINAL-redhat-1.jar:5.1.2.FINAL-redhat-1]
[JBossINF] at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:113) [infinispan-core-5.1.2.FINAL-redhat-1.jar:5.1.2.FINAL-redhat-1]
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:131) [infinispan-core-5.1.2.FINAL-redhat-1.jar:5.1.2.FINAL-redhat-1]
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) [infinispan-core-5.1.2.FINAL-redhat-1.jar:5.1.2.FINAL-redhat-1]
[JBossINF] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:130) [infinispan-core-5.1.2.FINAL-redhat-1.jar:5.1.2.FINAL-redhat-1]
[JBossINF] at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager$ClassLoaderAwareCommandInterceptor.handleDefault(DefaultEmbeddedCacheManager.java:410) [jboss-as-clustering-infinispan-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
[JBossINF] at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:113) [infinispan-core-5.1.2.FINAL-redhat-1.jar:5.1.2.FINAL-redhat-1]
[JBossINF] at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:131) [infinispan-core-5.1.2.FINAL-redhat-1.jar:5.1.2.FINAL-redhat-1]
[JBossINF] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:345) [infinispan-core-5.1.2.FINAL-redhat-1.jar:5.1.2.FINAL-redhat-1]
[JBossINF] at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:174) [infinispan-core-5.1.2.FINAL-redhat-1.jar:5.1.2.FINAL-redhat-1]
[JBossINF] at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:81) [infinispan-core-5.1.2.FINAL-redhat-1.jar:5.1.2.FINAL-redhat-1]
[JBossINF] at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:272) [infinispan-core-5.1.2.FINAL-redhat-1.jar:5.1.2.FINAL-redhat-1]
[JBossINF] at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:321) [infinispan-core-5.1.2.FINAL-redhat-1.jar:5.1.2.FINAL-redhat-1]
[JBossINF] at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:90) [infinispan-core-5.1.2.FINAL-redhat-1.jar:5.1.2.FINAL-redhat-1]
[JBossINF] at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:100) [infinispan-core-5.1.2.FINAL-redhat-1.jar:5.1.2.FINAL-redhat-1]
[JBossINF] at org.jboss.as.clustering.web.impl.TransactionBatchingManager.endBatch(TransactionBatchingManager.java:75) [jboss-as-clustering-web-spi-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
[JBossINF] at org.jboss.as.web.session.DistributableSessionManager.processSessionRepl(DistributableSessionManager.java:1530)
[JBossINF] at org.jboss.as.web.session.DistributableSessionManager.storeSession(DistributableSessionManager.java:865)
[JBossINF] at org.jboss.as.web.session.InstantSnapshotManager.snapshot(InstantSnapshotManager.java:47)
[JBossINF] at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:133)
[JBossINF] at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:91)
[JBossINF] at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:88)
[JBossINF] at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:56)
[JBossINF] at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:154)
[JBossINF] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
[JBossINF] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
[JBossINF] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
[JBossINF] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)
[JBossINF] at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:505)
[JBossINF] at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:445)
[JBossINF] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930)
[JBossINF] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
{noformat}
This likely results in timeout on the clients (that you see in the runs).
{noformat}
Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: IO error: java.net.SocketTimeoutException: Read timed out>
org.jboss.smartfrog.loaddriver.RequestProcessingException: IO error: java.net.SocketTimeoutException: Read timed out
at org.jboss.smartfrog.loaddriver.http.HttpRequestProcessorFactoryImpl$HttpRequestProcessor.processRequest(HttpRequestProcessorFactoryImpl.java:218)
at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
at org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:78)
at org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:106)
at org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1116)
at org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1973)
at org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1735)
at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1098)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
at org.jboss.smartfrog.loaddriver.http.HttpRequestProcessorFactoryImpl$HttpRequestProcessor.processRequest(HttpRequestProcessorFactoryImpl.java:132)
... 3 more
{noformat}
--
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
12 years, 2 months