[JBoss JIRA] (JGRP-1910) MERGE3: Do not lose any members from view during a series of merges
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1910?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1910:
---------------------------
Description:
When connection between nodes is re-established, MERGE3 should merge the cluster together. This often does not involve a single MergeView but a series of such events. The problematic property of this protocol is that some of those views can lack certain members, though these are reachable.
This causes problem in Infinispan since the cache cannot be fully rebalanced before another merge arrives, and all owners of certain segment can be gradually removed (and added again) to the view, while this is not detected as partition but crashed nodes -> losing all owners means data loss.
Removing members from view should be the role of FDx protocols, not MERGEx.
was:
When connection between nodes is re-estabilished, MERGE3 should merge the cluster together. This often does not involve a single MergeView but a series of such events. The problematic property of this protocol is that some of those views can lack certain members, though these are reachable.
This causes problem in Infinispan since the cache cannot be fully rebalanced before another merge arrives, and all owners of certain segment can be gradually removed (and added again) to the view, while this is not detected as partition but crashed nodes -> losing all owners means data loss.
Removing members from view should be the role of FDx protocols, not MERGEx.
> MERGE3: Do not lose any members from view during a series of merges
> -------------------------------------------------------------------
>
> Key: JGRP-1910
> URL: https://issues.jboss.org/browse/JGRP-1910
> Project: JGroups
> Issue Type: Bug
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.6.3
>
> Attachments: SplitMergeTest.java
>
>
> When connection between nodes is re-established, MERGE3 should merge the cluster together. This often does not involve a single MergeView but a series of such events. The problematic property of this protocol is that some of those views can lack certain members, though these are reachable.
> This causes problem in Infinispan since the cache cannot be fully rebalanced before another merge arrives, and all owners of certain segment can be gradually removed (and added again) to the view, while this is not detected as partition but crashed nodes -> losing all owners means data loss.
> Removing members from view should be the role of FDx protocols, not MERGEx.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (JGRP-1913) COMPRESS: ArrayOutOfBoundsException
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1913?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1913:
---------------------------
Description:
The exception shown below causes {{COMPRESS}} to drop *an already delivered message*, so the app won't receive it. As {{NAKACK2}} considers the message (or batch) _delivered_, it won't retransmit it. The effect is that the app won't receive it.
{noformat}
java.lang.ArrayIndexOutOfBoundsException
at org.jgroups.util.Headers.<init>(Headers.java:43)
at org.jgroups.Message.createHeaders(Message.java:953)
at org.jgroups.Message.copy(Message.java:581)
at org.jgroups.Message.copy(Message.java:552)
at org.jgroups.protocols.COMPRESS.uncompress(COMPRESS.java:175)
at org.jgroups.protocols.COMPRESS.up(COMPRESS.java:149)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:182)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:447)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:447)
at org.jgroups.stack.Protocol.up(Protocol.java:420)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294)
at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:474)
at org.jgroups.protocols.pbcast.NAKACK2.deliverBatch(NAKACK2.java:983)
at org.jgroups.protocols.pbcast.NAKACK2.removeAndPassUp(NAKACK2.java:912)
at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:846)
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:618)
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:200)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:297)
at org.jgroups.protocols.MERGE3.up(MERGE3.java:288)
at org.jgroups.protocols.Discovery.up(Discovery.java:291)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1577)
at org.jgroups.protocols.TP$3.run(TP.java:1511)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
{noformat}
was:
{noformat}
java.lang.ArrayIndexOutOfBoundsException
at org.jgroups.util.Headers.<init>(Headers.java:43)
at org.jgroups.Message.createHeaders(Message.java:953)
at org.jgroups.Message.copy(Message.java:581)
at org.jgroups.Message.copy(Message.java:552)
at org.jgroups.protocols.COMPRESS.uncompress(COMPRESS.java:175)
at org.jgroups.protocols.COMPRESS.up(COMPRESS.java:149)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:182)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:447)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:447)
at org.jgroups.stack.Protocol.up(Protocol.java:420)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294)
at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:474)
at org.jgroups.protocols.pbcast.NAKACK2.deliverBatch(NAKACK2.java:983)
at org.jgroups.protocols.pbcast.NAKACK2.removeAndPassUp(NAKACK2.java:912)
at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:846)
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:618)
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:200)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:297)
at org.jgroups.protocols.MERGE3.up(MERGE3.java:288)
at org.jgroups.protocols.Discovery.up(Discovery.java:291)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1577)
at org.jgroups.protocols.TP$3.run(TP.java:1511)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
{noformat}
> COMPRESS: ArrayOutOfBoundsException
> -----------------------------------
>
> Key: JGRP-1913
> URL: https://issues.jboss.org/browse/JGRP-1913
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4.8, 3.6.3
>
> Attachments: carsten.xml
>
>
> The exception shown below causes {{COMPRESS}} to drop *an already delivered message*, so the app won't receive it. As {{NAKACK2}} considers the message (or batch) _delivered_, it won't retransmit it. The effect is that the app won't receive it.
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException
> at org.jgroups.util.Headers.<init>(Headers.java:43)
> at org.jgroups.Message.createHeaders(Message.java:953)
> at org.jgroups.Message.copy(Message.java:581)
> at org.jgroups.Message.copy(Message.java:552)
> at org.jgroups.protocols.COMPRESS.uncompress(COMPRESS.java:175)
> at org.jgroups.protocols.COMPRESS.up(COMPRESS.java:149)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:182)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:447)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:447)
> at org.jgroups.stack.Protocol.up(Protocol.java:420)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:474)
> at org.jgroups.protocols.pbcast.NAKACK2.deliverBatch(NAKACK2.java:983)
> at org.jgroups.protocols.pbcast.NAKACK2.removeAndPassUp(NAKACK2.java:912)
> at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:846)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:618)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:200)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:297)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:288)
> at org.jgroups.protocols.Discovery.up(Discovery.java:291)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1577)
> at org.jgroups.protocols.TP$3.run(TP.java:1511)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (JGRP-1913) COMPRESS: ArrayOutOfBoundsException
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1913?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1913:
---------------------------
Fix Version/s: 3.4.8
> COMPRESS: ArrayOutOfBoundsException
> -----------------------------------
>
> Key: JGRP-1913
> URL: https://issues.jboss.org/browse/JGRP-1913
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4.8, 3.6.3
>
> Attachments: carsten.xml
>
>
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException
> at org.jgroups.util.Headers.<init>(Headers.java:43)
> at org.jgroups.Message.createHeaders(Message.java:953)
> at org.jgroups.Message.copy(Message.java:581)
> at org.jgroups.Message.copy(Message.java:552)
> at org.jgroups.protocols.COMPRESS.uncompress(COMPRESS.java:175)
> at org.jgroups.protocols.COMPRESS.up(COMPRESS.java:149)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:182)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:447)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:447)
> at org.jgroups.stack.Protocol.up(Protocol.java:420)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:474)
> at org.jgroups.protocols.pbcast.NAKACK2.deliverBatch(NAKACK2.java:983)
> at org.jgroups.protocols.pbcast.NAKACK2.removeAndPassUp(NAKACK2.java:912)
> at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:846)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:618)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:200)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:297)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:288)
> at org.jgroups.protocols.Discovery.up(Discovery.java:291)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1577)
> at org.jgroups.protocols.TP$3.run(TP.java:1511)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (JGRP-1913) COMPRESS: ArrayOutOfBoundsException
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1913?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1913.
----------------------------
Resolution: Done
Fixed by adding write synchronization to {{Headers}}
> COMPRESS: ArrayOutOfBoundsException
> -----------------------------------
>
> Key: JGRP-1913
> URL: https://issues.jboss.org/browse/JGRP-1913
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.3
>
> Attachments: carsten.xml
>
>
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException
> at org.jgroups.util.Headers.<init>(Headers.java:43)
> at org.jgroups.Message.createHeaders(Message.java:953)
> at org.jgroups.Message.copy(Message.java:581)
> at org.jgroups.Message.copy(Message.java:552)
> at org.jgroups.protocols.COMPRESS.uncompress(COMPRESS.java:175)
> at org.jgroups.protocols.COMPRESS.up(COMPRESS.java:149)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:182)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:447)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:447)
> at org.jgroups.stack.Protocol.up(Protocol.java:420)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:474)
> at org.jgroups.protocols.pbcast.NAKACK2.deliverBatch(NAKACK2.java:983)
> at org.jgroups.protocols.pbcast.NAKACK2.removeAndPassUp(NAKACK2.java:912)
> at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:846)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:618)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:200)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:297)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:288)
> at org.jgroups.protocols.Discovery.up(Discovery.java:291)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1577)
> at org.jgroups.protocols.TP$3.run(TP.java:1511)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFLY-4198) NullPointerException in LogDiagnosticContextRecoveryInterceptor when calling an asynchronous EJB
by Carlo de Wolf (JIRA)
[ https://issues.jboss.org/browse/WFLY-4198?page=com.atlassian.jira.plugin.... ]
Carlo de Wolf updated WFLY-4198:
--------------------------------
Description:
When trying to call an asynchronous EJB in a Web application using slf4j (1.7.5+) & logback(1.0.13+) for logging the following NullPointerException occurs (see below).
The problem is in the line 67 of LogDiagnosticContextRecoveryInterceptor class, when it tries to access MDC map, which is null. According to SLF4J API the copy of MDC map may be null: see the javadoc of org.slf4j.MDC#getCopyOfContextMap.
So LogDiagnosticContextRecoveryInterceptor or org.jboss.logging.Slf4jLoggerProvider have to check the map for null.
Currently there is no workaround for that :(.
{noformat}
Caused by: java.lang.NullPointerException
at org.jboss.as.ejb3.component.interceptors.LogDiagnosticContextRecoveryInterceptor.processInvocation(LogDiagnosticContextRecoveryInterceptor.java:67)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.as.ejb3.component.interceptors.AsyncFutureInterceptorFactory$1$2.runInvocation(AsyncFutureInterceptorFactory.java:97)
at org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.run(AsyncInvocationTask.java:73)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
at org.jboss.threads.JBossThread.run(JBossThread.java:122)
{noformat}
was:
When trying to call an asynchronous EJB in a Web application using slf4j (1.7.5+) & logback(1.0.13+) for logging the following NullPointerException occurs (see below).
The problem is in the line 67 of LogDiagnosticContextRecoveryInterceptor class, when it tries to access MDC map, which is null. According to SLF4J API the copy of MDC map may be null: see the javadoc of org.slf4j.MDC#getCopyOfContextMap.
So LogDiagnosticContextRecoveryInterceptor or org.jboss.logging.Slf4jLoggerProvider have to check the map for null.
Currently there is no workaround for that :(.
Caused by: java.lang.NullPointerException
at org.jboss.as.ejb3.component.interceptors.LogDiagnosticContextRecoveryInterceptor.processInvocation(LogDiagnosticContextRecoveryInterceptor.java:67)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.as.ejb3.component.interceptors.AsyncFutureInterceptorFactory$1$2.runInvocation(AsyncFutureInterceptorFactory.java:97)
at org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.run(AsyncInvocationTask.java:73)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> NullPointerException in LogDiagnosticContextRecoveryInterceptor when calling an asynchronous EJB
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-4198
> URL: https://issues.jboss.org/browse/WFLY-4198
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.2.0.Final
> Reporter: Sergiy Barlabanov
> Assignee: Bartosz Baranowski
>
> When trying to call an asynchronous EJB in a Web application using slf4j (1.7.5+) & logback(1.0.13+) for logging the following NullPointerException occurs (see below).
> The problem is in the line 67 of LogDiagnosticContextRecoveryInterceptor class, when it tries to access MDC map, which is null. According to SLF4J API the copy of MDC map may be null: see the javadoc of org.slf4j.MDC#getCopyOfContextMap.
> So LogDiagnosticContextRecoveryInterceptor or org.jboss.logging.Slf4jLoggerProvider have to check the map for null.
> Currently there is no workaround for that :(.
> {noformat}
> Caused by: java.lang.NullPointerException
> at org.jboss.as.ejb3.component.interceptors.LogDiagnosticContextRecoveryInterceptor.processInvocation(LogDiagnosticContextRecoveryInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.AsyncFutureInterceptorFactory$1$2.runInvocation(AsyncFutureInterceptorFactory.java:97)
> at org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.run(AsyncInvocationTask.java:73)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFLY-3991) JDK 1.8 javax.script.ScriptEngineFactory: Provider com.sun.script.javascript.RhinoScriptEngineFactory not found
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3991?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-3991:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1194705, https://bugzilla.redhat.com/show_bug.cgi?id=1195150 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1194705)
> JDK 1.8 javax.script.ScriptEngineFactory: Provider com.sun.script.javascript.RhinoScriptEngineFactory not found
> ---------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3991
> URL: https://issues.jboss.org/browse/WFLY-3991
> Project: WildFly
> Issue Type: Enhancement
> Reporter: Manuel Blechschmidt
> Assignee: Jason Greene
> Labels: JS223, JavaScript, Scripting
>
> When using the ScriptManager in a JSF bean the following happens:
> ERROR [stderr] (default task-21) ScriptEngineManager providers.next(): javax.script.ScriptEngineFactory: Provider com.sun.script.javascript.RhinoScriptEngineFactory not found
> {code}
> package de.example.log.jsf;
> import java.io.ByteArrayOutputStream;
> import java.io.IOException;
> import java.io.PrintStream;
> import javax.enterprise.inject.Model;
> import javax.faces.application.FacesMessage;
> import javax.faces.context.FacesContext;
> import javax.inject.Inject;
> import javax.script.Bindings;
> import javax.script.ScriptEngine;
> import javax.script.ScriptEngineManager;
> import javax.script.ScriptException;
> @Model
> public class Scripting {
> private String script;
> private String output;
> private ScriptEngineManager mgr = new ScriptEngineManager();
> public static String utilJavaScript = "var print = function (s) { __newOut.print(s); }; var println = function (s) { __newOut.println(s); };";
> public String execute() {
> ScriptEngine jsEngine = mgr.getEngineByName("JavaScript");
> ByteArrayOutputStream outputBuffer = new ByteArrayOutputStream(8192);
> PrintStream newOut = new PrintStream(outputBuffer, true);
> Bindings bindings = jsEngine.createBindings();
> bindings.put("__newOut", newOut);
> try {
> jsEngine.eval(utilJavaScript + getScript(), bindings);
> } catch (ScriptException from) {
> FacesContext.getCurrentInstance().addMessage(
> null,
> new FacesMessage(from.getColumnNumber() + " "
> + from.getFileName() + " " + from.getLineNumber()
> + " " + from.getMessage()));
> return null;
> }
> newOut.close();
> String returnString = outputBuffer.toString();
> setOutput(returnString);
> try {
> outputBuffer.close();
> } catch (IOException e) {
> FacesContext.getCurrentInstance().addMessage(
> null,
> new FacesMessage(e.getLocalizedMessage()));
> }
> return null;
> }
> public String getScript() {
> return script;
> }
> public void setScript(String script) {
> this.script = script;
> }
> public String getOutput() {
> return output;
> }
> public void setOutput(String output) {
> this.output = output;
> }
> }
> {code}
> The script engines are configured in the following file:
> WILDFLY_HOME/modules/system/layers/base/sun/jdk/main/service-loader-resources/META-INF/services/javax.script.ScriptEngineFactory
> {code}
> com.sun.script.javascript.RhinoScriptEngineFactory
> jdk.nashorn.api.scripting.NashornScriptEngineFactory
> {code}
> It should be made sure that with every JDK JSR 223 compliant requests for a JavaScript engine will work out of the box.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFLY-4379) Always expose <transaction-support> for resource adapters
by Jesper Pedersen (JIRA)
Jesper Pedersen created WFLY-4379:
-------------------------------------
Summary: Always expose <transaction-support> for resource adapters
Key: WFLY-4379
URL: https://issues.jboss.org/browse/WFLY-4379
Project: WildFly
Issue Type: Task
Components: JCA
Reporter: Jesper Pedersen
Assignee: Stefano Maestri
Fix For: 9.0.0.CR1
The <transaction-support> setting for resource adapters should always be exposed in the DMR model - e.g. no "undefined".
If the value isn't explicit defined by the deployment, then it will be obtained from the metadata repository of the archive in question.
This also makes it clear that <xa-pool> is used for XATransaction deployments.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (JGRP-1913) COMPRESS: ArrayOutOfBoundsException
by Bela Ban (JIRA)
Bela Ban created JGRP-1913:
------------------------------
Summary: COMPRESS: ArrayOutOfBoundsException
Key: JGRP-1913
URL: https://issues.jboss.org/browse/JGRP-1913
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.6.3
Attachments: carsten.xml
{noformat}
java.lang.ArrayIndexOutOfBoundsException
at org.jgroups.util.Headers.<init>(Headers.java:43)
at org.jgroups.Message.createHeaders(Message.java:953)
at org.jgroups.Message.copy(Message.java:581)
at org.jgroups.Message.copy(Message.java:552)
at org.jgroups.protocols.COMPRESS.uncompress(COMPRESS.java:175)
at org.jgroups.protocols.COMPRESS.up(COMPRESS.java:149)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:182)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:447)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:447)
at org.jgroups.stack.Protocol.up(Protocol.java:420)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294)
at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:474)
at org.jgroups.protocols.pbcast.NAKACK2.deliverBatch(NAKACK2.java:983)
at org.jgroups.protocols.pbcast.NAKACK2.removeAndPassUp(NAKACK2.java:912)
at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:846)
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:618)
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:200)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:297)
at org.jgroups.protocols.MERGE3.up(MERGE3.java:288)
at org.jgroups.protocols.Discovery.up(Discovery.java:291)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1577)
at org.jgroups.protocols.TP$3.run(TP.java:1511)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (JGRP-1913) COMPRESS: ArrayOutOfBoundsException
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1913?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1913:
---------------------------
Attachment: carsten.xml
Use {{MPerf}} with the attached configuration to reproduce. Single member
> COMPRESS: ArrayOutOfBoundsException
> -----------------------------------
>
> Key: JGRP-1913
> URL: https://issues.jboss.org/browse/JGRP-1913
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.3
>
> Attachments: carsten.xml
>
>
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException
> at org.jgroups.util.Headers.<init>(Headers.java:43)
> at org.jgroups.Message.createHeaders(Message.java:953)
> at org.jgroups.Message.copy(Message.java:581)
> at org.jgroups.Message.copy(Message.java:552)
> at org.jgroups.protocols.COMPRESS.uncompress(COMPRESS.java:175)
> at org.jgroups.protocols.COMPRESS.up(COMPRESS.java:149)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:182)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:447)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:447)
> at org.jgroups.stack.Protocol.up(Protocol.java:420)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:474)
> at org.jgroups.protocols.pbcast.NAKACK2.deliverBatch(NAKACK2.java:983)
> at org.jgroups.protocols.pbcast.NAKACK2.removeAndPassUp(NAKACK2.java:912)
> at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:846)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:618)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:200)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:297)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:288)
> at org.jgroups.protocols.Discovery.up(Discovery.java:291)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1577)
> at org.jgroups.protocols.TP$3.run(TP.java:1511)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (DROOLS-718) Reloading KJAR which contains DSL and RDSLR via KieScanner fails.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-718?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-718:
------------------------------------------------
Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1195125|https://bugzilla.redhat.com/show_bug.cgi?id=1195125] from ASSIGNED to MODIFIED
> Reloading KJAR which contains DSL and RDSLR via KieScanner fails.
> -----------------------------------------------------------------
>
> Key: DROOLS-718
> URL: https://issues.jboss.org/browse/DROOLS-718
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.2.0.CR4
> Environment: Mac OS X 10.10.2, Oracle HotSpot 1.7.0_71
> Reporter: Duncan Doyle
> Assignee: Mario Fusco
>
> When using the KieScanner to reload a KJAR with a DSL and RDSLR, reloading fails due to that the compiler is unable to find mappings for the language in the RDSLR.
> This is the error I get in my reproducer:
> 2015-02-18 00:45:02,764 [ERROR] [main] [org.drools.compiler.kie.builder.impl.KieContainerImpl] ERROR Unable to update KieBase: KBase1 to release org.kie:scanner-test:1.0-SNAPSHOT
> [7] No mapping entries for expanding: There is a SimpleFact
> [7] Unable to expand: There is a SimpleFact
> [8] No mapping entries for expanding: -with id "2"
> [8] Unable to expand: -with id "2"
> [10] No mapping entries for expanding: Print "Found a simple fact with id 2."
> [10] Unable to expand: Print "Found a simple fact with id 2."
> [7,7]: [ERR 102] Line 7:7 mismatched input 'is' in rule "bla"
> Reproducer project can be found here: https://github.com/DuncanDoyle/brms-kjar-with-dsl-kiescanner
> Just clone the repo and run 'mvn clean test'.
> Note that the reproducer creates the first KJAR, runs test, and then creates the second KJAR. Compilation of the second KJAR fails. When you alter the test to only load the second KJAR, everything works fine.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months