[JBoss JIRA] (ELY-1664) Trace logging in SSLUtils
by Justin Cook (JIRA)
[ https://issues.jboss.org/browse/ELY-1664?page=com.atlassian.jira.plugin.s... ]
Justin Cook commented on ELY-1664:
----------------------------------
The throw is in a return lambda so the trace will still be reached, with the SSLUtils::throwIt being needed for the SSLContext class is still returned.
> Trace logging in SSLUtils
> -------------------------
>
> Key: ELY-1664
> URL: https://issues.jboss.org/browse/ELY-1664
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Affects Versions: 1.6.0.Final
> Reporter: Martin Choma
> Assignee: Justin Cook
>
> Check Trace logging of ssl context creation. How I read code logging should apply after throw expression. That wouldn never happen. Also there is another throw of exception with SSLUtils::throwIt.
> {code:java|title=org.wildfly.security.ssl.SSLUtils}
> // now return a factory that will return the best match is can create.
> final String[] supportedProtocols = protocolSelector.evaluate(preferredProviderByAlgorithm.keySet().toArray(NO_STRINGS));
> if (supportedProtocols.length > 0) {
> return () -> {
> for (String protocol : supportedProtocols) {
> List<Provider> providerList = preferredProviderByAlgorithm.getOrDefault(protocol, Collections.emptyList());
> for (Provider provider : providerList) {
> try {
> return SSLContext.getInstance(protocol, provider);
> } catch (NoSuchAlgorithmException ignored) {}
> }
> }
> throw ElytronMessages.log.noAlgorithmForSslProtocol();
> };
> }
> if (log.isTraceEnabled()) {
> log.tracef("No %s provided by providers in %s: %s", SERVICE_TYPE, SSLUtils.class.getSimpleName(), Arrays.toString(providerSupplier.get()));
> }
> return SSLUtils::throwIt;
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFCORE-4105) Create simple tests for scripts
by James Perkins (JIRA)
James Perkins created WFCORE-4105:
-------------------------------------
Summary: Create simple tests for scripts
Key: WFCORE-4105
URL: https://issues.jboss.org/browse/WFCORE-4105
Project: WildFly Core
Issue Type: Task
Components: Scripts, Test Suite
Reporter: James Perkins
Assignee: James Perkins
Currently scripts are really only ever tested manually. If the developer making changes to the script does not have an environment to execute the scripts in, e.g. changing a {{*.bat}} script and not having a Windows machine, we may not know immediately if the change breaks anything. A simple test suite should be introduced which tests the scripts based on the environment.
Note that at this point the tests are not be exhaustive and are not meant to test several combinations of parameters. The tests are only to ensure the scripts work on the various environments.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-10661) IllegalMonitorStateException if session invalidated after redirect
by Adam Krajcik (JIRA)
[ https://issues.jboss.org/browse/WFLY-10661?page=com.atlassian.jira.plugin... ]
Adam Krajcik commented on WFLY-10661:
-------------------------------------
[~pferraro], I just deployed the war attached to this JIRA , started server via standalone.sh and went to http://localhost:8080/undertow1374/. Bash commands below:
{code}
cp undertow1374.war wildfly-15.0.0.Alpha1-SNAPSHOT/standalone/deployments/
wildfly-15.0.0.Alpha1-SNAPSHOT/bin/standalone.sh
curl -L http://localhost:8080/undertow1374
{code}
>From what I could see, it fails on {{request.getSession().invalidate()}} in the following code
{code}
<%
response.sendRedirect("/foobar");
request.getSession().invalidate();
%>
{code}
Here is the complete [^stacktrace.txt].
> IllegalMonitorStateException if session invalidated after redirect
> ------------------------------------------------------------------
>
> Key: WFLY-10661
> URL: https://issues.jboss.org/browse/WFLY-10661
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Environment: EAP 7.1.3
> Reporter: Aaron Ogburn
> Assignee: Paul Ferraro
> Priority: Minor
> Fix For: 14.0.0.Beta2
>
> Attachments: stacktrace.txt, undertow1374.war
>
>
> response.sendRedirect unlocks the session. So attempting session.invalidate after any sendRedirect throws an IllegalMonitorStateException when it attempts to unlock it again:
> {code}
> 16:35:11,267 INFO [stdout] (default task-1) --------------------------->StampedLock.unlock java.util.concurrent.locks.StampedLock@2a03fe4a[Unlocked] 257
> 16:35:11,267 INFO [stdout] (default task-1) java.util.concurrent.locks.StampedLock.unlock(StampedLock.java:603)
> 16:35:11,267 INFO [stdout] (default task-1) org.wildfly.clustering.web.undertow.session.DistributableSessionManager.lambda$getSessionCloseTask$1(DistributableSessionManager.java:103)
> 16:35:11,267 INFO [stdout] (default task-1) org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:96)
> 16:35:11,267 INFO [stdout] (default task-1) io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:860)
> 16:35:11,267 INFO [stdout] (default task-1) io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:572)
> 16:35:11,267 INFO [stdout] (default task-1) io.undertow.servlet.spec.HttpServletResponseImpl.sendRedirect(HttpServletResponseImpl.java:203)
> 16:35:11,267 INFO [stdout] (default task-1) org.apache.jsp.hi_jsp._jspService(hi_jsp.java:136)
> ...
> Caused by: java.lang.IllegalMonitorStateException
> at java.util.concurrent.locks.StampedLock.unlock(StampedLock.java:609)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.lambda$getSessionCloseTask$1(DistributableSessionManager.java:103)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:218)
> at io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:198)
> at org.apache.jsp.hi_jsp._jspService(hi_jsp.java:137)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-10661) IllegalMonitorStateException if session invalidated after redirect
by Adam Krajcik (JIRA)
[ https://issues.jboss.org/browse/WFLY-10661?page=com.atlassian.jira.plugin... ]
Adam Krajcik updated WFLY-10661:
--------------------------------
Attachment: stacktrace.txt
> IllegalMonitorStateException if session invalidated after redirect
> ------------------------------------------------------------------
>
> Key: WFLY-10661
> URL: https://issues.jboss.org/browse/WFLY-10661
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Environment: EAP 7.1.3
> Reporter: Aaron Ogburn
> Assignee: Paul Ferraro
> Priority: Minor
> Fix For: 14.0.0.Beta2
>
> Attachments: stacktrace.txt, undertow1374.war
>
>
> response.sendRedirect unlocks the session. So attempting session.invalidate after any sendRedirect throws an IllegalMonitorStateException when it attempts to unlock it again:
> {code}
> 16:35:11,267 INFO [stdout] (default task-1) --------------------------->StampedLock.unlock java.util.concurrent.locks.StampedLock@2a03fe4a[Unlocked] 257
> 16:35:11,267 INFO [stdout] (default task-1) java.util.concurrent.locks.StampedLock.unlock(StampedLock.java:603)
> 16:35:11,267 INFO [stdout] (default task-1) org.wildfly.clustering.web.undertow.session.DistributableSessionManager.lambda$getSessionCloseTask$1(DistributableSessionManager.java:103)
> 16:35:11,267 INFO [stdout] (default task-1) org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:96)
> 16:35:11,267 INFO [stdout] (default task-1) io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:860)
> 16:35:11,267 INFO [stdout] (default task-1) io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:572)
> 16:35:11,267 INFO [stdout] (default task-1) io.undertow.servlet.spec.HttpServletResponseImpl.sendRedirect(HttpServletResponseImpl.java:203)
> 16:35:11,267 INFO [stdout] (default task-1) org.apache.jsp.hi_jsp._jspService(hi_jsp.java:136)
> ...
> Caused by: java.lang.IllegalMonitorStateException
> at java.util.concurrent.locks.StampedLock.unlock(StampedLock.java:609)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.lambda$getSessionCloseTask$1(DistributableSessionManager.java:103)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:218)
> at io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:198)
> at org.apache.jsp.hi_jsp._jspService(hi_jsp.java:137)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-9529) Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry
by Scott Van Wart (JIRA)
[ https://issues.jboss.org/browse/WFLY-9529?page=com.atlassian.jira.plugin.... ]
Scott Van Wart commented on WFLY-9529:
--------------------------------------
Confirmed in 14.0.1.Final:
{noformat}
2018-09-11 12:56:52,695 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 14.0.1.Final (WildFly Core 6.0.2.Final) started in 994ms - Started 620 of 794 services (350 services are lazy, passive or on-demand)
2018-09-11 12:56:55,625 INFO [test.service.TestServiceImpl] (EE-ManagedExecutorService-default-Thread-1) Message out: Message from background task
2018-09-11 12:56:55,628 SEVERE [test.service.BackgroundTaskImpl] (EE-ManagedExecutorService-default-Thread-1) java.lang.RuntimeException: javax.naming.NameNotFoundException: java:comp/TransactionSynchronizationRegistry
at org.wildfly.extension.messaging.activemq.deployment.injection.InjectedJMSContext.lookup(InjectedJMSContext.java:145)
at org.wildfly.extension.messaging.activemq.deployment.injection.InjectedJMSContext.getTransactionSynchronizationRegistry(InjectedJMSContext.java:120)
at org.wildfly.extension.messaging.activemq.deployment.injection.InjectedJMSContext.isInTransaction(InjectedJMSContext.java:109)
at org.wildfly.extension.messaging.activemq.deployment.injection.InjectedJMSContext.getDelegate(InjectedJMSContext.java:87)
at org.wildfly.extension.messaging.activemq.deployment.injection.JMSContextWrapper.createTextMessage(JMSContextWrapper.java:157)
at test.service.TestServiceImpl.sendMessage(TestServiceImpl.java:61)
at test.service.TestServiceImpl$Proxy$_$$_WeldSubclass.sendMessage$$super(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.weld.interceptor.proxy.TerminalAroundInvokeInvocationContext.proceedInternal(TerminalAroundInvokeInvocationContext.java:51)
at org.jboss.weld.interceptor.proxy.AroundInvokeInvocationContext.proceed(AroundInvokeInvocationContext.java:78)
at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:174)
at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.doIntercept(TransactionalInterceptorRequired.java:53)
at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.intercept(TransactionalInterceptorBase.java:88)
at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.intercept(TransactionalInterceptorRequired.java:47)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73)
at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeAroundInvoke(InterceptorMethodHandler.java:84)
at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:72)
at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:56)
at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:79)
at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:68)
at test.service.TestServiceImpl$Proxy$_$$_WeldSubclass.sendMessage(Unknown Source)
at test.service.TestServiceImpl$Proxy$_$$_WeldClientProxy.sendMessage(Unknown Source)
at test.service.BackgroundTaskImpl.run(BackgroundTaskImpl.java:31)
at org.jboss.as.ee.concurrent.ControlPointUtils$ControlledRunnable.run(ControlPointUtils.java:105)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.glassfish.enterprise.concurrent.internal.ManagedFutureTask.run(ManagedFutureTask.java:141)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:250)
at org.jboss.as.ee.concurrent.service.ElytronManagedThreadFactory$ElytronManagedThread.run(ElytronManagedThreadFactory.java:78)
Caused by: javax.naming.NameNotFoundException: java:comp/TransactionSynchronizationRegistry
at org.jboss.as.naming.InitialContext$DefaultInitialContext.findContext(InitialContext.java:191)
at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:235)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at org.wildfly.extension.messaging.activemq.deployment.injection.InjectedJMSContext.lookup(InjectedJMSContext.java:143)
... 38 more
{noformat}
> Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9529
> URL: https://issues.jboss.org/browse/WFLY-9529
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, JMS, Naming
> Affects Versions: 14.0.1.Final, 10.1.0.Final, 11.0.0.Final, 12.0.0.Final, 13.0.0.Final
> Environment: Running on Windows 10, Java 64-bit 1.8.0_131
> Reporter: Scott Van Wart
> Assignee: Eduardo Martins
> Labels: ActiveMQ, jms, transaction
> Attachments: injected-jms.zip, injected-jms2.zip, wildfly-11-injected-jms.txt
>
>
> If I try to use an @Injected JMSContext while executing within a background task (ManagedExecutorService) or thread (ManagedThreadFactory), I get the attached stacktrace. I've experienced this a number of times with Wildfly 10.1.0, including messages sent in Infinispan's expiry task thread.
> My original workaround was to submit an additional task on a separate thread to send the message, then wait for it to complete. That seemed unreliable (sometimes it would still produce NameNotFoundException). I've resorted to creating my own JMSContext by using @Resource( lookup="java:/ConnectionFactory" ) and sending messages that way. Both workarounds prevent the message sending logic from participating in any ongoing transactions.
> I'm also attaching a sample EAR project. It can be built with Maven. It creates a background task that waits 3 seconds and then tries to send a JMS message in a new transaction using an injected JMS context. I use the standalone-full.xml profile to run it.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-9529) Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry
by Scott Van Wart (JIRA)
[ https://issues.jboss.org/browse/WFLY-9529?page=com.atlassian.jira.plugin.... ]
Scott Van Wart updated WFLY-9529:
---------------------------------
Affects Version/s: 14.0.1.Final
> Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9529
> URL: https://issues.jboss.org/browse/WFLY-9529
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, JMS, Naming
> Affects Versions: 14.0.1.Final, 10.1.0.Final, 11.0.0.Final, 12.0.0.Final, 13.0.0.Final
> Environment: Running on Windows 10, Java 64-bit 1.8.0_131
> Reporter: Scott Van Wart
> Assignee: Eduardo Martins
> Labels: ActiveMQ, jms, transaction
> Attachments: injected-jms.zip, injected-jms2.zip, wildfly-11-injected-jms.txt
>
>
> If I try to use an @Injected JMSContext while executing within a background task (ManagedExecutorService) or thread (ManagedThreadFactory), I get the attached stacktrace. I've experienced this a number of times with Wildfly 10.1.0, including messages sent in Infinispan's expiry task thread.
> My original workaround was to submit an additional task on a separate thread to send the message, then wait for it to complete. That seemed unreliable (sometimes it would still produce NameNotFoundException). I've resorted to creating my own JMSContext by using @Resource( lookup="java:/ConnectionFactory" ) and sending messages that way. Both workarounds prevent the message sending logic from participating in any ongoing transactions.
> I'm also attaching a sample EAR project. It can be built with Maven. It creates a background task that waits 3 seconds and then tries to send a JMS message in a new transaction using an injected JMS context. I use the standalone-full.xml profile to run it.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (DROOLS-2804) [DMN Designer] Properties Panel to drill-down to DMN component level
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2804?page=com.atlassian.jira.plugi... ]
Michael Anstis updated DROOLS-2804:
-----------------------------------
Priority: Critical (was: Major)
> [DMN Designer] Properties Panel to drill-down to DMN component level
> --------------------------------------------------------------------
>
> Key: DROOLS-2804
> URL: https://issues.jboss.org/browse/DROOLS-2804
> Project: Drools
> Issue Type: Feature Request
> Components: DMN Editor
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Priority: Critical
> Labels: drools-tools
>
> The Properties Panel currently shows properties for Stunner-level "graph" components.
> We need, for DMN, the Properties Panel to show the properties of DMN elements' properties at the "grid" level. For example, when a {{Context}} is selected the Properties Panel should show only the top level properties for the {{Context}} (i.e. not those of its {{ContextEntries}}). Selection of a {{ContextEntry}} should refresh the Properties Panel to show only the top-level properties of the {{ContextEntry}}. Selection of the {{ContextEntry}}'s {{Expression}} should again refresh the Properties Panel to show only the top-level properties of the {{Expression}} and so forth.
> h2. Properties on the Grid Level
> The selection on the grid level should show the properties below. Please notice that selection of multiple cells, rows or columns should show empty properties panel.
> h3. Literal expression
> ||Selected item||Properties panel items||
> |Cell|(?)|
> h3. Context
> ||Selected item||Properties panel items||
> |Row|(?)|
> |Column|(?)|
> |Cell|(?)|
> h3. Decision Table
> ||Selected item||Properties panel items||
> |Row|(?)|
> |Column|(?)|
> |Cell|(?)|
> h3. Relation
> ||Selected item||Properties panel items||
> |Row|(?)|
> |Column|(?)|
> |Cell|(?)|
> h3. Function
> ||Selected item||Properties panel items||
> |Row|(?)|
> |Column|(?)|
> |Cell|(?)|
> h3. Invocation
> ||Selected item||Properties panel items||
> |Row|(?)|
> |Column|(?)|
> |Cell|(?)|
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-10661) IllegalMonitorStateException if session invalidated after redirect
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10661?page=com.atlassian.jira.plugin... ]
Paul Ferraro commented on WFLY-10661:
-------------------------------------
[~adamkrajcik] Given this trace, this looks like a different bug. Can you be specific about to reproduce this ? Which session operation causes this? Can you attach the rest of the stack trace?
> IllegalMonitorStateException if session invalidated after redirect
> ------------------------------------------------------------------
>
> Key: WFLY-10661
> URL: https://issues.jboss.org/browse/WFLY-10661
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Environment: EAP 7.1.3
> Reporter: Aaron Ogburn
> Assignee: Paul Ferraro
> Priority: Minor
> Fix For: 14.0.0.Beta2
>
> Attachments: undertow1374.war
>
>
> response.sendRedirect unlocks the session. So attempting session.invalidate after any sendRedirect throws an IllegalMonitorStateException when it attempts to unlock it again:
> {code}
> 16:35:11,267 INFO [stdout] (default task-1) --------------------------->StampedLock.unlock java.util.concurrent.locks.StampedLock@2a03fe4a[Unlocked] 257
> 16:35:11,267 INFO [stdout] (default task-1) java.util.concurrent.locks.StampedLock.unlock(StampedLock.java:603)
> 16:35:11,267 INFO [stdout] (default task-1) org.wildfly.clustering.web.undertow.session.DistributableSessionManager.lambda$getSessionCloseTask$1(DistributableSessionManager.java:103)
> 16:35:11,267 INFO [stdout] (default task-1) org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:96)
> 16:35:11,267 INFO [stdout] (default task-1) io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:860)
> 16:35:11,267 INFO [stdout] (default task-1) io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:572)
> 16:35:11,267 INFO [stdout] (default task-1) io.undertow.servlet.spec.HttpServletResponseImpl.sendRedirect(HttpServletResponseImpl.java:203)
> 16:35:11,267 INFO [stdout] (default task-1) org.apache.jsp.hi_jsp._jspService(hi_jsp.java:136)
> ...
> Caused by: java.lang.IllegalMonitorStateException
> at java.util.concurrent.locks.StampedLock.unlock(StampedLock.java:609)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.lambda$getSessionCloseTask$1(DistributableSessionManager.java:103)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:218)
> at io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:198)
> at org.apache.jsp.hi_jsp._jspService(hi_jsp.java:137)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-10741) Relicense Quickstarts and BOMs as Apache 2.0
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-10741?page=com.atlassian.jira.plugin... ]
Kabir Khan updated WFLY-10741:
------------------------------
Description:
There has been a bit back and forth on the bom and QS licenses in WF12, 13 and 14. For WF15, we should relicense them all (where possible) to Apache 2.0.
Note that we will need:
A LICENCE.txt in the root folder
The name of the license in the BOMs should be from the 'Full Name' column of https://spdx.org/licenses/
was:There has been a bit back and forth on the bom and QS licenses in WF12, 13 and 14. For WF15, we should relicense them all (where possible) to Apache 2.0
> Relicense Quickstarts and BOMs as Apache 2.0
> --------------------------------------------
>
> Key: WFLY-10741
> URL: https://issues.jboss.org/browse/WFLY-10741
> Project: WildFly
> Issue Type: Task
> Components: Quickstarts
> Reporter: Kabir Khan
> Assignee: Eduardo Martins
>
> There has been a bit back and forth on the bom and QS licenses in WF12, 13 and 14. For WF15, we should relicense them all (where possible) to Apache 2.0.
> Note that we will need:
> A LICENCE.txt in the root folder
> The name of the license in the BOMs should be from the 'Full Name' column of https://spdx.org/licenses/
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-10736) Server in cluster hangs during start after previous kill
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10736?page=com.atlassian.jira.plugin... ]
Paul Ferraro commented on WFLY-10736:
-------------------------------------
[~mnovak] I've run the test several times against WF master and am unable to reproduce the hanging on startup issue you've described.
However, I was able to to trigger the condition where the kill + immediate restart resulted in the node rejoining the view before the failure was detected, which is the condition a brief delay (btw, a 100 ms delay should be more than sufficient) is meant to avoid.
e.g.
10:48:03,832 INFO [org.infinispan.CLUSTER] (thread-10,ejb,node-1) ISPN000094: Received new cluster view for channel ejb: [node-1|2] (3) [node-1, node-2, node-2]
It results in a bunch of these types of messages in the log:
10:43:31,179 WARN [org.jgroups.protocols.UDP] (TQ-Bundler-4,ejb,node-2) JGRP000032: node-2: no physical address for ca513176-f399-8926-dd35-4ac36a4946ff, dropping message
But, even so, this does not appear to cause the test to fail.
> Server in cluster hangs during start after previous kill
> --------------------------------------------------------
>
> Key: WFLY-10736
> URL: https://issues.jboss.org/browse/WFLY-10736
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Reporter: Miroslav Novak
> Assignee: Paul Ferraro
> Priority: Blocker
> Labels: blocker-WF14
> Fix For: 15.0.0.Alpha1
>
> Attachments: Lodh2TestCase.testRemoteJcaInboundOnly-traces.zip, Lodh2TestCase.testRemoteJcaInboundOnly.zip, Lodh2TestCase.testRemoteJcaInboundOnly2.zip, clusterKilTest.zip, logs-traces.zip, logs-traces2.zip, logs-traces3.zip, logs-traces4.zip, logs-with-workaround.zip, node-1-thread-dump-before-kill-shutdown-sequence.txt, server-with-mdb.log, standalone-full-ha-1.xml, standalone-full-ha-2.xml
>
>
> There is regression in JGroups or Infinispan in one of our tests for fault tolerance of JMS bridges. However work on JMS bridge appears to be unrelated. Issue was hit in WF weekly run.
> Test Scenario:
> * There are two servers. InQueue is deployed on Node 1,
> * OutQueue is deployed on Node 2. Both servers are started.
> * Large byte messages are sent to InQueue deployed on Node 1. Bridge between servers/queues transfers messages from node 1 to node 2.
> * Node 1 is killed and started again.
> * All messages are received from OutQueue deployed on Node 2.
> Result:
> Node 1 does not start after kill and hangs. There is following exception logged in node 2:
> {code}
> :26:17,894 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100000: Node node-1 joined the cluster
> 09:26:18,520 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN000094: Received new cluster view for channel ejb: [node-2|7] (2) [node-2, node-1]
> 09:26:18,521 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100001: Node node-1 left the cluster
> 09:26:18,521 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN000094: Received new cluster view for channel ejb: [node-2|7] (2) [node-2, node-1]
> 09:26:18,522 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100001: Node node-1 left the cluster
> 09:26:18,522 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN000094: Received new cluster view for channel ejb: [node-2|7] (2) [node-2, node-1]
> 09:26:18,522 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100001: Node node-1 left the cluster
> 09:26:18,522 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN000094: Received new cluster view for channel ejb: [node-2|7] (2) [node-2, node-1]
> 09:26:18,523 INFO [org.infinispan.CLUSTER] (thread-12,ejb,node-2) ISPN100001: Node node-1 left the cluster
> 09:26:18,868 INFO [org.infinispan.CLUSTER] (remote-thread--p5-t2) ISPN000310: Starting cluster-wide rebalance for cache default, topology CacheTopology{id=17, phase=READ_OLD_WRITE_ALL, rebalanceId=6, currentCH=ReplicatedConsistentHash{ns = 256, owners = (2)[node-2: 122, node-1: 134]}, pendingCH=ReplicatedConsistentHash{ns = 256, owners = (3)[node-2: 84, node-1: 90, node-1: 82]}, unionCH=null, actualMembers=[node-2, node-1, node-1], persistentUUIDs=[12443bfb-e88a-46f3-919e-9213bf38ce19, 2873237f-d881-463f-8a5a-940bf1d764e5, a05ea8af-a83b-42a9-b937-dc2da1cae6d1]}
> 09:26:18,869 INFO [org.infinispan.CLUSTER] (remote-thread--p5-t2) [Context=default][Scope=node-2]ISPN100002: Started rebalance with topology id 17
> 09:26:18,870 INFO [org.infinispan.CLUSTER] (transport-thread--p14-t5) [Context=default][Scope=node-2]ISPN100003: Node node-2 finished rebalance phase with topology id 17
> 09:26:18,981 INFO [org.infinispan.CLUSTER] (remote-thread--p5-t2) [Context=default][Scope=node-1]ISPN100003: Node node-1 finished rebalance phase with topology id 17
> 09:27:18,530 WARN [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread--p15-t4) ISPN000197: Error updating cluster member list: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> Suppressed: java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357) [rt.jar:1.8.0_131]
> at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1915) [rt.jar:1.8.0_131]
> at org.infinispan.util.concurrent.CompletableFutures.await(CompletableFutures.java:82)
> at org.infinispan.remoting.transport.Transport.invokeRemotely(Transport.java:71)
> at org.infinispan.topology.ClusterTopologyManagerImpl.confirmMembersAvailable(ClusterTopologyManagerImpl.java:540)
> at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheMembers(ClusterTopologyManagerImpl.java:523)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleClusterView(ClusterTopologyManagerImpl.java:334)
> at org.infinispan.topology.ClusterTopologyManagerImpl.access$500(ClusterTopologyManagerImpl.java:85)
> at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.lambda$handleViewChange$0(ClusterTopologyManagerImpl.java:745)
> at org.infinispan.executors.LimitedExecutor.runTasks(LimitedExecutor.java:144)
> at org.infinispan.executors.LimitedExecutor.access$100(LimitedExecutor.java:33)
> at org.infinispan.executors.LimitedExecutor$Runner.run(LimitedExecutor.java:174)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47)
> ... 1 more
> Caused by: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> ... 1 more
> [CIRCULAR REFERENCE:java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1]
> 09:27:18,530 WARN [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread--p16-t4) ISPN000197: Error updating cluster member list: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> Suppressed: java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357) [rt.jar:1.8.0_131]
> at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1915) [rt.jar:1.8.0_131]
> at org.infinispan.util.concurrent.CompletableFutures.await(CompletableFutures.java:82)
> at org.infinispan.remoting.transport.Transport.invokeRemotely(Transport.java:71)
> at org.infinispan.topology.ClusterTopologyManagerImpl.confirmMembersAvailable(ClusterTopologyManagerImpl.java:540)
> at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheMembers(ClusterTopologyManagerImpl.java:523)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleClusterView(ClusterTopologyManagerImpl.java:334)
> at org.infinispan.topology.ClusterTopologyManagerImpl.access$500(ClusterTopologyManagerImpl.java:85)
> at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.lambda$handleViewChange$0(ClusterTopologyManagerImpl.java:745)
> at org.infinispan.executors.LimitedExecutor.runTasks(LimitedExecutor.java:144)
> at org.infinispan.executors.LimitedExecutor.access$100(LimitedExecutor.java:33)
> at org.infinispan.executors.LimitedExecutor$Runner.run(LimitedExecutor.java:174)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47)
> ... 1 more
> Caused by: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_131]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> ... 1 more
> [CIRCULAR REFERENCE:java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 4 from node-1]
> {code}
> There is default JGroups udp stack configured which is used by Infinispan. Both of the servers (jgroups udp) are bound to 127.0.0.1. Node 2 has port offset 1000.
> Attaching thread dump from node 1 when it hangs during start.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months