[JBoss JIRA] (JGRP-2336) Probe: add support for running on TCP
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2336?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2336:
---------------------------
Description:
Probe / DiagnosticsHandler currently only supports UDP / IP multicasting.
Add support for listening on TCP sockets. In this case, probe.sh needs to be invoked with the address of _one_ member, e.g. {{probe.sh -aadr 192.168.1.5}}.
This will help to run JGroups on GraalVM (JGRP-2332) as MulticastSocket is currently not supported (see {{./doc/design/PortingToGraalVM.txt}} for details).
was:
Probe / DiagnosticsHandler currently only supports UDP / IP multicasting.
Add support for listening on TCP sockets. In this case, probe.sh needs to be invoked with the address of _one_ member, e.g. {{probe.sh -aadr 192.168.1.5}}
> Probe: add support for running on TCP
> -------------------------------------
>
> Key: JGRP-2336
> URL: https://issues.jboss.org/browse/JGRP-2336
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.0
>
>
> Probe / DiagnosticsHandler currently only supports UDP / IP multicasting.
> Add support for listening on TCP sockets. In this case, probe.sh needs to be invoked with the address of _one_ member, e.g. {{probe.sh -aadr 192.168.1.5}}.
> This will help to run JGroups on GraalVM (JGRP-2332) as MulticastSocket is currently not supported (see {{./doc/design/PortingToGraalVM.txt}} for details).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months
[JBoss JIRA] (JGRP-2336) Probe: add support for running on TCP
by Bela Ban (Jira)
Bela Ban created JGRP-2336:
------------------------------
Summary: Probe: add support for running on TCP
Key: JGRP-2336
URL: https://issues.jboss.org/browse/JGRP-2336
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 4.1.0
Probe / DiagnosticsHandler currently only supports UDP / IP multicasting.
Add support for listening on TCP sockets. In this case, probe.sh needs to be invoked with the address of _one_ member, e.g. {{probe.sh -aadr 192.168.1.5}}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months
[JBoss JIRA] (WFLY-11906) Managed Executor Task Fails with CDI if created from Batchlet
by Matěj Novotný (Jira)
[ https://issues.jboss.org/browse/WFLY-11906?page=com.atlassian.jira.plugin... ]
Matěj Novotný edited comment on WFLY-11906 at 3/28/19 4:33 AM:
---------------------------------------------------------------
[~cfang] FYI *something must have changed around thread pool that batch uses* as in WFLY 14 calling {{Thread.currentThread().getContextClassLoader()}} returns {{ModuleClassLoader for Module "deployment.demo.war" from Service Module Loader}} while in 16 this is different (see my comment above).
That explains why the first option(_Start Batch with Send using Managed Exectuor_) worked in 14 but doesn't in 16.
Nonetheless, this doesn't solve the trouble we have with async events and with the fact that users can even use custom executors.
was (Author: manovotn):
[~cfang] FYI *something must have changed around thread pool that batch uses* as in WFLY 14 calling {{Thread.currentThread().getContextClassLoader()}} returns {{ModuleClassLoader for Module "deployment.demo.war" from Service Module Loader}} while in 16 this is different (see my comment above).
That explains why the first option worked in 14 but doesn't in 16.
Nonetheless, this doesn't solve the trouble we have with async events and with the fact that users can even use custom executors.
> Managed Executor Task Fails with CDI if created from Batchlet
> -------------------------------------------------------------
>
> Key: WFLY-11906
> URL: https://issues.jboss.org/browse/WFLY-11906
> Project: WildFly
> Issue Type: Bug
> Components: Batch, CDI / Weld, Concurrency Utilities
> Affects Versions: 16.0.0.Final
> Environment: Java 8
> Reporter: Cody Lerum
> Assignee: Cheng Fang
> Priority: Major
>
> This previously was working (verified in reproducer) on Wildfly 14.0.1
> Inside of a batchlet if a Managed Executor Task is executed and that Task uses CDI.current() an exception is thrown
> {code:java}
> 11:00:02,343 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) java.lang.IllegalStateException: WFLYWELD0039: Singleton not set for ModuleClassLoader for Module "org.jboss.as.ee" version 16.0.0.Final from local module loader @78e94dcf (finder: local module finder @233fe9b6 (roots: V:\opt\wildfly-16.0.0.Final\modules,V:\opt\wildfly-16.0.0.Final\modules\system\layers\base)). This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> 11:00:02,344 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:77)
> 11:00:02,344 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:134)
> 11:00:02,344 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.weld.Container.instance(Container.java:57)
> 11:00:02,344 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.as.weld.WeldProvider.getCDI(WeldProvider.java:69)
> 11:00:02,344 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at javax.enterprise.inject.spi.CDI.lambda$getCDIProvider$0(CDI.java:87)
> 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:174)
> 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.TreeMap$KeySpliterator.tryAdvance(TreeMap.java:2770)
> 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:126)
> 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:498)
> 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:485)
> 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.FindOps$FindOp.evaluateSequential(FindOps.java:152)
> 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.ReferencePipeline.findFirst(ReferencePipeline.java:464)
> 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at javax.enterprise.inject.spi.CDI.getCDIProvider(CDI.java:88)
> 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at javax.enterprise.inject.spi.CDI.current(CDI.java:64)
> 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at com.outjected.demo.DemoTask.run(DemoTask.java:27)
> 11:00:02,347 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.as.ee.concurrent.ControlPointUtils$ControlledRunnable.run(ControlPointUtils.java:105)
> 11:00:02,347 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 11:00:02,347 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:266)
> 11:00:02,347 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.concurrent.FutureTask.run(FutureTask.java)
> 11:00:02,348 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.glassfish.enterprise.concurrent.internal.ManagedFutureTask.run(ManagedFutureTask.java:141)
> 11:00:02,348 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 11:00:02,348 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 11:00:02,348 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.lang.Thread.run(Thread.java:748)
> 11:00:02,349 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:250)
> 11:00:02,349 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.as.ee.concurrent.service.ElytronManagedThreadFactory$ElytronManagedThread.run(ElytronManagedThreadFactory.java:85)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months
[JBoss JIRA] (WFLY-11906) Managed Executor Task Fails with CDI if created from Batchlet
by Matěj Novotný (Jira)
[ https://issues.jboss.org/browse/WFLY-11906?page=com.atlassian.jira.plugin... ]
Matěj Novotný commented on WFLY-11906:
--------------------------------------
[~cfang] FYI *something must have changed around thread pool that batch uses* as in WFLY 14 calling {{Thread.currentThread().getContextClassLoader()}} returns {{ModuleClassLoader for Module "deployment.demo.war" from Service Module Loader}} while in 16 this is different (see my comment above).
That explains why the first option worked in 14 but doesn't in 16.
Nonetheless, this doesn't solve the trouble we have with async events and with the fact that users can even use custom executors.
> Managed Executor Task Fails with CDI if created from Batchlet
> -------------------------------------------------------------
>
> Key: WFLY-11906
> URL: https://issues.jboss.org/browse/WFLY-11906
> Project: WildFly
> Issue Type: Bug
> Components: Batch, CDI / Weld, Concurrency Utilities
> Affects Versions: 16.0.0.Final
> Environment: Java 8
> Reporter: Cody Lerum
> Assignee: Cheng Fang
> Priority: Major
>
> This previously was working (verified in reproducer) on Wildfly 14.0.1
> Inside of a batchlet if a Managed Executor Task is executed and that Task uses CDI.current() an exception is thrown
> {code:java}
> 11:00:02,343 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) java.lang.IllegalStateException: WFLYWELD0039: Singleton not set for ModuleClassLoader for Module "org.jboss.as.ee" version 16.0.0.Final from local module loader @78e94dcf (finder: local module finder @233fe9b6 (roots: V:\opt\wildfly-16.0.0.Final\modules,V:\opt\wildfly-16.0.0.Final\modules\system\layers\base)). This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> 11:00:02,344 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:77)
> 11:00:02,344 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:134)
> 11:00:02,344 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.weld.Container.instance(Container.java:57)
> 11:00:02,344 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.as.weld.WeldProvider.getCDI(WeldProvider.java:69)
> 11:00:02,344 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at javax.enterprise.inject.spi.CDI.lambda$getCDIProvider$0(CDI.java:87)
> 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:174)
> 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.TreeMap$KeySpliterator.tryAdvance(TreeMap.java:2770)
> 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:126)
> 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:498)
> 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:485)
> 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.FindOps$FindOp.evaluateSequential(FindOps.java:152)
> 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.ReferencePipeline.findFirst(ReferencePipeline.java:464)
> 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at javax.enterprise.inject.spi.CDI.getCDIProvider(CDI.java:88)
> 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at javax.enterprise.inject.spi.CDI.current(CDI.java:64)
> 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at com.outjected.demo.DemoTask.run(DemoTask.java:27)
> 11:00:02,347 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.as.ee.concurrent.ControlPointUtils$ControlledRunnable.run(ControlPointUtils.java:105)
> 11:00:02,347 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 11:00:02,347 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:266)
> 11:00:02,347 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.concurrent.FutureTask.run(FutureTask.java)
> 11:00:02,348 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.glassfish.enterprise.concurrent.internal.ManagedFutureTask.run(ManagedFutureTask.java:141)
> 11:00:02,348 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 11:00:02,348 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 11:00:02,348 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.lang.Thread.run(Thread.java:748)
> 11:00:02,349 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:250)
> 11:00:02,349 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.as.ee.concurrent.service.ElytronManagedThreadFactory$ElytronManagedThread.run(ElytronManagedThreadFactory.java:85)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months
[JBoss JIRA] (DROOLS-3803) Build error with executable-model, nested property with double-bytes property name
by Hiroko Miura (Jira)
Hiroko Miura created DROOLS-3803:
------------------------------------
Summary: Build error with executable-model, nested property with double-bytes property name
Key: DROOLS-3803
URL: https://issues.jboss.org/browse/DROOLS-3803
Project: Drools
Issue Type: Bug
Components: executable model
Affects Versions: 7.18.0.Final
Environment: 7.18.0.Final
7.18.0.Final-redhat-00002 (RHDM7.3.0)
7.14.0.Final-redhat-00004 (RHDM7.1.2)
Reporter: Hiroko Miura
Assignee: Luca Molteni
Attachments: NestedPropertyTest.zip
Build of Executable Model fails with the following conditions in LHS:
* multi-bytes property name (or started with capital letter)
* accessing the property by the name without using getter.
* accessing nested property by `.`
e.g.
{noformat}
when
$fact : Fact( 住所.zipCode == "1000001")
...
{noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months
[JBoss JIRA] (DROOLS-3802) Build error with executable-model, nested property with double-bytes property name
by Hiroko Miura (Jira)
[ https://issues.jboss.org/browse/DROOLS-3802?page=com.atlassian.jira.plugi... ]
Hiroko Miura updated DROOLS-3802:
---------------------------------
Description:
Build of Executable Model fails with the following conditions in LHS:
* multi-bytes property name (or started with capital letter)
* accessing the property by the name without using getter.
* accessing nested property by `.`
e.g.
{noformat}
when
$fact : Fact( 住所.zipCode == "1000001")
...
{noformat}
was:
Build of Executable Model fails with the following conditions in LHS:
* multi-bytes property name (or started with capital letter)
* accessing the property by the name without using getter.
* accessing nested property by `.`
e.g.
{noformat}
when
$fact : Fact( 住所 .zipCode == "1000001")
...
{noformat}
> Build error with executable-model, nested property with double-bytes property name
> ----------------------------------------------------------------------------------
>
> Key: DROOLS-3802
> URL: https://issues.jboss.org/browse/DROOLS-3802
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.18.0.Final
> Environment: 7.18.0.Final
> 7.18.0.Final-redhat-00002 (RHDM7.3.0)
> 7.14.0.Final-redhat-00004 (RHDM7.1.2)
> Reporter: Hiroko Miura
> Assignee: Luca Molteni
> Priority: Major
> Labels: support
> Attachments: NestedPropertyTest.zip
>
>
> Build of Executable Model fails with the following conditions in LHS:
> * multi-bytes property name (or started with capital letter)
> * accessing the property by the name without using getter.
> * accessing nested property by `.`
> e.g.
> {noformat}
> when
> $fact : Fact( 住所.zipCode == "1000001")
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months
[JBoss JIRA] (DROOLS-3802) Build error with executable-model, nested property with double-bytes property name
by Hiroko Miura (Jira)
Hiroko Miura created DROOLS-3802:
------------------------------------
Summary: Build error with executable-model, nested property with double-bytes property name
Key: DROOLS-3802
URL: https://issues.jboss.org/browse/DROOLS-3802
Project: Drools
Issue Type: Bug
Components: executable model
Affects Versions: 7.18.0.Final
Environment: 7.18.0.Final
7.18.0.Final-redhat-00002 (RHDM7.3.0)
7.14.0.Final-redhat-00004 (RHDM7.1.2)
Reporter: Hiroko Miura
Assignee: Luca Molteni
Attachments: NestedPropertyTest.zip
Build of Executable Model fails with the following conditions in LHS:
* multi-bytes property name (or started with capital letter)
* accessing the property by the name without using getter.
* accessing nested property by `.`
e.g.
{noformat}
when
$fact : Fact( 住所 .zipCode == "1000001")
...
{noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months