[JBoss JIRA] (DROOLS-4750) DrlParser fails to parse str[endsWith] operator
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-4750?page=com.atlassian.jira.plugi... ]
Mario Fusco resolved DROOLS-4750.
---------------------------------
Resolution: Explained
What the knowledge builder does at some point is invoking this
{code}
new EvaluatorRegistry(this.getClass().getClassLoader());
{code}
which has the side-effect of registering the custom operators like 'str' into the parser. If you add that line as first statement of your first test you will see that it will also succeed. Note however that the DRLParser is an internal class that is not part of our public API and not intended for direct access by our end-users. For this reason I don't think that we should change it in any way to make it work also without a knowledge builder.
> DrlParser fails to parse str[endsWith] operator
> -----------------------------------------------
>
> Key: DROOLS-4750
> URL: https://issues.jboss.org/browse/DROOLS-4750
> Project: Drools
> Issue Type: Bug
> Reporter: Alberto Fanjul Alonso
> Assignee: Mario Fusco
> Priority: Major
> Attachments: reproducer.zip
>
>
> In documentation
> https://docs.jboss.org/drools/release/7.23.0.Final/drools-docs/html_singl...
> operator str[endsWith] is supposed to be supported, it it is not working.
> Fails with:
> {code:java}
> java.lang.Exception: Rule contains errors![[5,19]: [ERR 102] Line 5:19 mismatched input 'str' in rule "pnr first name end with"]
> at com.mdw.bzr.drools_reproducer.StrWithFailOnFirstCompilationErrorReproducerTest.parse(StrWithFailOnFirstCompilationErrorReproducerTest.java:58)
> at com.mdw.bzr.drools_reproducer.StrWithFailOnFirstCompilationErrorReproducerTest._03_parseStrWith(StrWithFailOnFirstCompilationErrorReproducerTest.java:74)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFCORE-4758) Simple config export for a domain server
by Brian Stansberry (Jira)
Brian Stansberry created WFCORE-4758:
----------------------------------------
Summary: Simple config export for a domain server
Key: WFCORE-4758
URL: https://issues.jboss.org/browse/WFCORE-4758
Project: WildFly Core
Issue Type: Feature Request
Components: CLI
Reporter: Brian Stansberry
Assignee: Jean Francois Denise
For a standalone server one can always pull the running configuration from the configuration dir, and can also use the root resource 'take-snapshot' op to persist a different file with the current content. But for a domain server there is no persistent form of the server's effective config and the 'take-snapshot' op is not exposed.
The 'read-config-as-xml' op was meant to help with this but unfortunately the CLI takes the output and escapes every quote before displaying it, which makes the output unusable without further manipulation.
Perhaps a high-level read-config-as-xml op?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFLY-12824) Clustering: java.lang.StackOverflowError in scattered cache scenarios
by Tommasso Borgato (Jira)
[ https://issues.jboss.org/browse/WFLY-12824?page=com.atlassian.jira.plugin... ]
Tommasso Borgato commented on WFLY-12824:
-----------------------------------------
I confirm the error is caused by:
{noformat}
/subsystem=infinispan/cache-container=web/scattered-cache=testScattered/component=state-transfer:add(timeout=0)
{noformat}
> Clustering: java.lang.StackOverflowError in scattered cache scenarios
> ---------------------------------------------------------------------
>
> Key: WFLY-12824
> URL: https://issues.jboss.org/browse/WFLY-12824
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 17.0.1.Final, 18.0.1.Final
> Reporter: Tommasso Borgato
> Assignee: Paul Ferraro
> Priority: Critical
>
> We are in clustering test using scattered cache where fail-over is introduced via server shutdown ([eap-7.x-clustering-http-session-shutdown-scattered|https://eap-qe-jenkins...]) and replication is set at the whole session level;
> Server configuration is:
> {noformat}
> embed-server --server-config=standalone-ha.xml
> /subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcp)
> /subsystem=infinispan/cache-container=web/scattered-cache=testScattered:add()
> /subsystem=infinispan/cache-container=web/scattered-cache=testScattered/component=state-transfer:add(timeout=0)
> /subsystem=infinispan/cache-container=web:write-attribute(name=default-cache, value=testScattered)
> {noformat}
> With all the following distributions:
> - [wildfly-18.0.1.Final.zip|https://download.jboss.org/wildfly/18.0.1.Final/...]
> - [wildfly-17.0.1.Final.zip|https://download.jboss.org/wildfly/17.0.1.Final/...]
> - [wildfly master|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/cluster...]
> we get {{java.lang.StackOverflowError}} after WildFly restart (complete logs [1|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x-clus...], [2|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x-clus...], [3|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x-clus...]):
> {noformat}
> 2019-11-24 18:30:00,221 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 86) WFLYCLINF0002: Started clusterbench-ee8.ear.clusterbench-ee8-web-passivating.war cache from web container
> 2019-11-24 18:30:00,837 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.clustering.web."clusterbench-ee8.ear.clusterbench-ee8-web.war": org.jboss.msc.service.StartException in service jboss.clustering.web."clusterbench-ee8.ear.clusterbench-ee8-web.war": org.infinispan.commons.CacheException: java.util.concurrent.ExecutionException: java.lang.StackOverflowError
> at org.wildfly.clustering.service@18.0.1.Final//org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:70)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: org.infinispan.commons.CacheException: java.util.concurrent.ExecutionException: java.lang.StackOverflowError
> at org.infinispan@9.4.16.Final//org.infinispan.interceptors.impl.PrefetchInterceptor$BackingIterator.hasNext(PrefetchInterceptor.java:651)
> at org.infinispan.commons@9.4.16.Final//org.infinispan.commons.util.IteratorMapper.hasNext(IteratorMapper.java:27)
> at org.wildfly.clustering.web.infinispan@18.0.1.Final//org.wildfly.clustering.web.infinispan.session.InfinispanSessionManagerFactory.schedule(InfinispanSessionManagerFactory.java:232)
> at org.wildfly.clustering.web.infinispan(a)18.0.1.Final//org.wildfly.clustering.web.infinispan.session.InfinispanSessionManagerFactory.<init>(InfinispanSessionManagerFactory.java:120)
> at org.wildfly.clustering.web.infinispan@18.0.1.Final//org.wildfly.clustering.web.infinispan.session.InfinispanSessionManagerFactoryServiceConfigurator.get(InfinispanSessionManagerFactoryServiceConfigurator.java:92)
> at org.wildfly.clustering.web.infinispan@18.0.1.Final//org.wildfly.clustering.web.infinispan.session.InfinispanSessionManagerFactoryServiceConfigurator.get(InfinispanSessionManagerFactoryServiceConfigurator.java:69)
> at org.wildfly.clustering.service@18.0.1.Final//org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:67)
> ... 8 more
> Caused by: java.util.concurrent.ExecutionException: java.lang.StackOverflowError
> at java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:395)
> at java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2022)
> at org.infinispan@9.4.16.Final//org.infinispan.interceptors.impl.PrefetchInterceptor$BackingIterator.hasNext(PrefetchInterceptor.java:649)
> ... 14 more
> Caused by: java.lang.StackOverflowError
> at java.base/java.lang.Throwable.getMessage(Throwable.java:382)
> at java.base/java.lang.Throwable.getLocalizedMessage(Throwable.java:396)
> at java.base/java.lang.Throwable.toString(Throwable.java:485)
> at java.base/java.lang.Throwable.<init>(Throwable.java:316)
> at java.base/java.lang.Exception.<init>(Exception.java:102)
> at java.base/java.lang.RuntimeException.<init>(RuntimeException.java:96)
> at java.base/java.util.concurrent.CompletionException.<init>(CompletionException.java:88)
> at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
> at java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1113)
> at java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
> at org.infinispan@9.4.16.Final//org.infinispan.scattered.impl.ScatteredVersionManagerImpl.valuesFuture(ScatteredVersionManagerImpl.java:348)
> at org.infinispan@9.4.16.Final//org.infinispan.scattered.impl.ScatteredVersionManagerImpl.lambda$valuesFuture$3(ScatteredVersionManagerImpl.java:348)
> at java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
> at java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
> at org.infinispan@9.4.16.Final//org.infinispan.scattered.impl.ScatteredVersionManagerImpl.valuesFuture(ScatteredVersionManagerImpl.java:348)
> at org.infinispan@9.4.16.Final//org.infinispan.scattered.impl.ScatteredVersionManagerImpl.lambda$valuesFuture$3(ScatteredVersionManagerImpl.java:348)
> at java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
> at java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
> at org.infinispan@9.4.16.Final//org.infinispan.scattered.impl.ScatteredVersionManagerImpl.valuesFuture(ScatteredVersionManagerImpl.java:348)
> at org.infinispan@9.4.16.Final//org.infinispan.scattered.impl.ScatteredVersionManagerImpl.lambda$valuesFuture$3(ScatteredVersionManagerImpl.java:348)
> at java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
> at java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (JGRP-2106) Prepare for JDK 11
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2106?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2106:
---------------------------
Description: Investigate the changes needed to run with JDK 11. Probably module.info classes are all that's needed. (was: Investigate the changes needed to run with JDK 9. Probably module.info classes are all that's needed.)
> Prepare for JDK 11
> ------------------
>
> Key: JGRP-2106
> URL: https://issues.jboss.org/browse/JGRP-2106
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0
>
>
> Investigate the changes needed to run with JDK 11. Probably module.info classes are all that's needed.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (JGRP-2225) Allow for sending of message batches in JChannel and protocols
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2225?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2225:
--------------------------------
The equivalent to this in 5.0 is {{CompositeMessage}}. It achieves the same thing without the downsides of implementing down(MessageBatch).
> Allow for sending of message batches in JChannel and protocols
> --------------------------------------------------------------
>
> Key: JGRP-2225
> URL: https://issues.jboss.org/browse/JGRP-2225
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0
>
>
> Currently, we receive messages and message batches, but we're not able to _send_ message batches. Investigate adding a {{JChannel.send(MessageBatch)}} and {{Protocol.down(MessageBatch)}}.
> The use case is that if we want to send 10 messages to the same destination, we currently send 10 messages. Because they're on the same thread, they;re _not_ likely to end up in the same batch.
> Sending a message batch down the stack ensures that all messages end up in the same message batch (unless the max bundle size is exceeded).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (JGRP-2418) Impedence mismatch between message types and transports
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2418?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2418:
---------------------------
Description:
When sending a message (_of any type_), it is currently marshalled into a byte[] array, which is handled diffently by each transport:
* UDP wraps it into a DatagramPacket and calls DatagramSocket.send()
* TCP writes the array to the socket's output stream
* TCP_NIO2 wraps it into a {{ByteBuffer}} and calls SocketChannel.write(ByteBuffer)
In some cases, there is an impedance mismatch between the type of the message and the type of the transport: for example, when sending an NioMessage (containing a ByteBuffer), we don't actually need the conversion to byte array and the subsequent wrapping into a ByteBuffer, this is superfluous. Even worse, when using off-heap, this creates unneeded memory allocation. Passing the *same* ByteBuffer all the way down from the application to the transport would be beneficial.
This requires changes in the way bundlers accumulate messages. Also, perhaps the transport itself should become an SPI, to which a generic {{Transport}} protocol delegates. This would also allow up to implement multiple transports (JGRP-1424) in the same stack.
was:
When sending a message (_of any type_), it is currently marshalled into a byte[] array, which is handled diffently by each transport:
* UDP wraps it into a DatagramPacket and calls DatagramSocket.send()
* TCP writes the array to the socket's output stream
* TCP_NIO2 wraps it into a {{ByteBuffer}} and calls SocketChannel.write(ByteBuffer)
In some cases, there is an impedance mismatch between the type of the message and the type of the transport: for example, when sending an NioMessage (containing a ByteBuffer), we don't actually need the conversion to byte array and the subsequent wrapping into a ByteBuffer, this is superfluous. Even worse, when using off-heap, this creates unneeded memory allocation. Passing the *same* ByteBuffer all the way down from the application to the transport would be beneficial.
This requires changes in the way bundlers accumulate messages. Also, perhaps the transport itself should become an SPI, to which a generic {{Transport}} protocol delegates. This would also allow up to implement multiple transports in the same stack.
> Impedence mismatch between message types and transports
> -------------------------------------------------------
>
> Key: JGRP-2418
> URL: https://issues.jboss.org/browse/JGRP-2418
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.1
>
>
> When sending a message (_of any type_), it is currently marshalled into a byte[] array, which is handled diffently by each transport:
> * UDP wraps it into a DatagramPacket and calls DatagramSocket.send()
> * TCP writes the array to the socket's output stream
> * TCP_NIO2 wraps it into a {{ByteBuffer}} and calls SocketChannel.write(ByteBuffer)
> In some cases, there is an impedance mismatch between the type of the message and the type of the transport: for example, when sending an NioMessage (containing a ByteBuffer), we don't actually need the conversion to byte array and the subsequent wrapping into a ByteBuffer, this is superfluous. Even worse, when using off-heap, this creates unneeded memory allocation. Passing the *same* ByteBuffer all the way down from the application to the transport would be beneficial.
> This requires changes in the way bundlers accumulate messages. Also, perhaps the transport itself should become an SPI, to which a generic {{Transport}} protocol delegates. This would also allow up to implement multiple transports (JGRP-1424) in the same stack.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (JGRP-2418) Impedence mismatch between message types and transports
by Bela Ban (Jira)
Bela Ban created JGRP-2418:
------------------------------
Summary: Impedence mismatch between message types and transports
Key: JGRP-2418
URL: https://issues.jboss.org/browse/JGRP-2418
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 5.1
When sending a message (_of any type_), it is currently marshalled into a byte[] array, which is handled diffently by each transport:
* UDP wraps it into a DatagramPacket and calls DatagramSocket.send()
* TCP writes the array to the socket's output stream
* TCP_NIO2 wraps it into a {{ByteBuffer}} and calls SocketChannel.write(ByteBuffer)
In some cases, there is an impedance mismatch between the type of the message and the type of the transport: for example, when sending an NioMessage (containing a ByteBuffer), we don't actually need the conversion to byte array and the subsequent wrapping into a ByteBuffer, this is superfluous. Even worse, when using off-heap, this creates unneeded memory allocation. Passing the *same* ByteBuffer all the way down from the application to the transport would be beneficial.
This requires changes in the way bundlers accumulate messages. Also, perhaps the transport itself should become an SPI, to which a generic {{Transport}} protocol delegates. This would also allow up to implement multiple transports in the same stack.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months