[JBoss JIRA] (DROOLS-1566) Unable to lookup Stateless KieSession and KieBase from Remote Java Client
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1566?page=com.atlassian.jira.plugi... ]
Edson Tirelli resolved DROOLS-1566.
-----------------------------------
Resolution: Rejected
It is possible to invoke stateless sessions from the java client API for the kie-server. Here is an example:
https://github.com/kiegroup/droolsjbpm-integration/blob/master/kie-server...
> Unable to lookup Stateless KieSession and KieBase from Remote Java Client
> -------------------------------------------------------------------------
>
> Key: DROOLS-1566
> URL: https://issues.jboss.org/browse/DROOLS-1566
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.5.0.Final
> Reporter: Dhamodharan Krishnan
> Assignee: Edson Tirelli
>
> The rules that I define in Stateful or the default KieSession and KieBase are picked up the Remote Java client. The rules that I define in Stateless KieSessions or KieBase are not picked up.
> I am not able to define rules in Stateless Kie Session. And I get duplicate data as part of my response as the facts injected into the Working memory seems to get bundled.
> For eg, if a response POJO is supposed to contain 3 inner objects as part of its Response.
> Response.java
> {
> List<Person> personsList;
> }
> Lets assume that the response should contain 3 matching persons as part of its response.
> But each time, I hit the Kie Container from the Remote Java client, the results get bundled and it goes in Arithmetic progression as
> 3 , 6, 9, 12, 15, .... and so on until I restart my KieServer instance itself.
> Thats where I am not clear on how to configure the KieContainer to make sure the results are not bundled.
> Imagine, if I am going to call the Kie Container from different instances, it may even be giving wrong results .
> As it returns the stocked up data.
> Hope you understand my problem.
> Thats where I try to configure Stateless KieSession and map my package to that.
> But the remote Java client is not able to pick the Stateless KieSession.
> It picks only Stateful ones.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFCORE-2876) runtime-failure-causes-rollback does not seem to have effect when configured in model
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2876?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet edited comment on WFCORE-2876 at 5/29/17 1:02 PM:
--------------------------------------------------------------------
I don't reproduce the issue with a standalone instance on current build from master.
Also the test seems to be passing with it.
was (Author: ehugonnet):
I don't reproduce the issue with a standalone instance.
> runtime-failure-causes-rollback does not seem to have effect when configured in model
> -------------------------------------------------------------------------------------
>
> Key: WFCORE-2876
> URL: https://issues.jboss.org/browse/WFCORE-2876
> Project: WildFly Core
> Issue Type: Bug
> Components: Deployment Scanner
> Affects Versions: 3.0.0.Beta21
> Reporter: Miroslav Novak
> Assignee: ehsavoie Hugonnet
>
> This is follow up on discussion in WFCORE-1912. There is difference in behavior if deployment is deployed like:
> {code}deploy ~/tmp/mdb1.jar --unmanaged --headers={rollback-on-runtime-failure=false}{code}
> and if it's deployed by copying to deployments directory and setting {{rollback-on-runtime-failure=false}} in model:
> {code}
> /subsystem=deployment-scanner/scanner=default:write-attribute(name=runtime-failure-causes-rollback,value=false)
> {code}
> If it's deployed by the 1st way using CLI {{deploy}} command then If deployment is missing some dependencies (like connection factories, queues/topics) and those are added later then deployment is able recover from it and start working without need to reload/restart server or redeploy.
> However if it's deployed the 2nd way then deployment does not recover when missing dependencies are added. It looks like attribute {{runtime-failure-causes-rollback}} does not have the effect in this case.
> This is causing problems when Artemis is configured in colocated HA topology with replicated journal where it takes some time for Artemis to activate but deployment which depends on some connection factories and queues has already tried to deploy. We need deployment to recover from this situation automatically. Restart/Reload will not help in this case as it would end up in the same situation. Only manual redeploy will help which is a workaround.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFCORE-2876) runtime-failure-causes-rollback does not seem to have effect when configured in model
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2876?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet edited comment on WFCORE-2876 at 5/29/17 1:02 PM:
--------------------------------------------------------------------
I don't reproduce the issue with a standalone instance on current build from master.
Also the reproducer test seems to be passing with it.
was (Author: ehugonnet):
I don't reproduce the issue with a standalone instance on current build from master.
Also the test seems to be passing with it.
> runtime-failure-causes-rollback does not seem to have effect when configured in model
> -------------------------------------------------------------------------------------
>
> Key: WFCORE-2876
> URL: https://issues.jboss.org/browse/WFCORE-2876
> Project: WildFly Core
> Issue Type: Bug
> Components: Deployment Scanner
> Affects Versions: 3.0.0.Beta21
> Reporter: Miroslav Novak
> Assignee: ehsavoie Hugonnet
>
> This is follow up on discussion in WFCORE-1912. There is difference in behavior if deployment is deployed like:
> {code}deploy ~/tmp/mdb1.jar --unmanaged --headers={rollback-on-runtime-failure=false}{code}
> and if it's deployed by copying to deployments directory and setting {{rollback-on-runtime-failure=false}} in model:
> {code}
> /subsystem=deployment-scanner/scanner=default:write-attribute(name=runtime-failure-causes-rollback,value=false)
> {code}
> If it's deployed by the 1st way using CLI {{deploy}} command then If deployment is missing some dependencies (like connection factories, queues/topics) and those are added later then deployment is able recover from it and start working without need to reload/restart server or redeploy.
> However if it's deployed the 2nd way then deployment does not recover when missing dependencies are added. It looks like attribute {{runtime-failure-causes-rollback}} does not have the effect in this case.
> This is causing problems when Artemis is configured in colocated HA topology with replicated journal where it takes some time for Artemis to activate but deployment which depends on some connection factories and queues has already tried to deploy. We need deployment to recover from this situation automatically. Restart/Reload will not help in this case as it would end up in the same situation. Only manual redeploy will help which is a workaround.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFCORE-2876) runtime-failure-causes-rollback does not seem to have effect when configured in model
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2876?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet commented on WFCORE-2876:
-------------------------------------------
I don't reproduce the issue with a standalone instance.
> runtime-failure-causes-rollback does not seem to have effect when configured in model
> -------------------------------------------------------------------------------------
>
> Key: WFCORE-2876
> URL: https://issues.jboss.org/browse/WFCORE-2876
> Project: WildFly Core
> Issue Type: Bug
> Components: Deployment Scanner
> Affects Versions: 3.0.0.Beta21
> Reporter: Miroslav Novak
> Assignee: ehsavoie Hugonnet
>
> This is follow up on discussion in WFCORE-1912. There is difference in behavior if deployment is deployed like:
> {code}deploy ~/tmp/mdb1.jar --unmanaged --headers={rollback-on-runtime-failure=false}{code}
> and if it's deployed by copying to deployments directory and setting {{rollback-on-runtime-failure=false}} in model:
> {code}
> /subsystem=deployment-scanner/scanner=default:write-attribute(name=runtime-failure-causes-rollback,value=false)
> {code}
> If it's deployed by the 1st way using CLI {{deploy}} command then If deployment is missing some dependencies (like connection factories, queues/topics) and those are added later then deployment is able recover from it and start working without need to reload/restart server or redeploy.
> However if it's deployed the 2nd way then deployment does not recover when missing dependencies are added. It looks like attribute {{runtime-failure-causes-rollback}} does not have the effect in this case.
> This is causing problems when Artemis is configured in colocated HA topology with replicated journal where it takes some time for Artemis to activate but deployment which depends on some connection factories and queues has already tried to deploy. We need deployment to recover from this situation automatically. Restart/Reload will not help in this case as it would end up in the same situation. Only manual redeploy will help which is a workaround.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8855) Deny CLI export/import journal if JDBC persistence storage is configured
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-8855?page=com.atlassian.jira.plugin.... ]
ehsavoie Hugonnet moved JBEAP-11200 to WFLY-8855:
-------------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8855 (was: JBEAP-11200)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JMS
(was: JMS)
(was: User Experience)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR9)
(was: 7.1.0.DR18)
> Deny CLI export/import journal if JDBC persistence storage is configured
> ------------------------------------------------------------------------
>
> Key: WFLY-8855
> URL: https://issues.jboss.org/browse/WFLY-8855
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 11.0.0.Alpha1
> Reporter: ehsavoie Hugonnet
> Assignee: Jeff Mesnil
> Priority: Minor
>
> As it is written in analysis document \[1\] for EAP7-591, journal import/export command is not supported for JDBC persistence storage because Artemis doesn't provide any management operation for it.
> Currently the operation still exports data from (or imports to) local file journal even the JDBC storage is configured. The operations should be denied in this case or there should be warning which will inform admin that this is not export that he wants.
> \[1\] https://developer.jboss.org/wiki/DevAnalysisForEAP7-591-ProvideSupportFor...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFCORE-2301) Mount point not found exception raised by createTempFileWithAttributes on overlayfs [JDK-8165852]
by Bjoern Stuetz (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2301?page=com.atlassian.jira.plugi... ]
Bjoern Stuetz commented on WFCORE-2301:
---------------------------------------
Hi [~brian.stansberry], I meant to respond much much much earlier; I am very sorry for that. Just wanted to say many thanks for your help and wanted to confirm that we had no problems any more at all after your WFCORE-2301 fix. Thanks heaps!
> Mount point not found exception raised by createTempFileWithAttributes on overlayfs [JDK-8165852]
> -------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2301
> URL: https://issues.jboss.org/browse/WFCORE-2301
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Environment: WildFly via KeyCloak 2.5.1.Final
> {code:xml}
> <eap.version>7.0.0.Beta</eap.version>
> <jboss.as.version>7.2.0.Final</jboss.as.version>
> <wildfly.version>10.0.0.Final</wildfly.version>
> {code}
> on Docker with overlayfs or overlayfs2 as storage driver
> \# docker info | grep -i storage
> aufs: works (e.g., boot2docker, legacy minikube)
> overlay (e.g., CoreOS, current minikube): problem
> devicemapper (e.g., CentOS): works
> overlay2 (e.g., Docker for Mac): problem
> Reporter: Bjoern Stuetz
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Beta3, 2.2.1.CR2
>
>
> Mount point not found exception raised by createTempFileWithAttributes on overlayfs [JDK-8165852], i.e.,
> /opt/jboss/bin/jboss-cli.sh --file=/opt/jboss/jboss-config.cli
> inside a Docker container running on overlayfs as storage driver
> causes (full stack trace below):
> {code:java}
> java.io.IOException: Mount point not foundImage
> at sun.nio.fs.LinuxFileStore.findMountEntry(LinuxFileStore.java:91)
> {code}
> triggered by
> {code:java}
> at org.jboss.as.controller.persistence.FilePersistenceUtils.createTempFileWithAttributes(FilePersistenceUtils.java:117)
> at org.jboss.as.controller.persistence.FilePersistenceUtils.writeToTempFile(FilePersistenceUtils.java:104)
> {code}
> due to OpenJDK bug/overlayfs bug.
> We acknowledge that this is in fact an OpenJDK AND/OR overlayfs bug. However everything seems to run fine in WildFly except once the backup of the config is triggered, for example by using the cli. Hence WildFly is of limited functionality when the more and more popular overlayfs storage driver is used, and the WildFly team might be interested in providing a workaround on their side since there is no indication the OpenJDK bug will be promptly fixed. We are happy to help in any way, we are still trying to find a workaround on the Java or WildFly side; but we might need insights on why findMountEntry is invoked.
> Full Stack Trace:
> {code:java}
> java.io.IOException: Mount point not foundImage
> at sun.nio.fs.LinuxFileStore.findMountEntry(LinuxFileStore.java:91)
> at sun.nio.fs.UnixFileStore.<init>(UnixFileStore.java:65)
> at sun.nio.fs.LinuxFileStore.<init>(LinuxFileStore.java:44)
> at sun.nio.fs.LinuxFileSystemProvider.getFileStore(LinuxFileSystemProvider.java:51)
> at sun.nio.fs.LinuxFileSystemProvider.getFileStore(LinuxFileSystemProvider.java:39)
> at sun.nio.fs.UnixFileSystemProvider.getFileStore(UnixFileSystemProvider.java:368)
> at java.nio.file.Files.getFileStore(Files.java:1461)
> at org.jboss.as.controller.persistence.FilePersistenceUtils.getPosixAttributes(FilePersistenceUtils.java:129)
> at org.jboss.as.controller.persistence.FilePersistenceUtils.createTempFileWithAttributes(FilePersistenceUtils.java:117)
> at org.jboss.as.controller.persistence.FilePersistenceUtils.writeToTempFile(FilePersistenceUtils.java:104)
> at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.doCommit(ConfigurationFilePersistenceResource.java:55)
> at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.commit(AbstractFilePersistenceResource.java:58)
> at org.jboss.as.controller.ModelControllerImpl$4.commit(ModelControllerImpl.java:781)
> at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:743)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:204)
> at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:659)
> at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:649)
> at org.jboss.as.controller.client.helpers.DelegatingModelControllerClient.execute(DelegatingModelControllerClient.java:63)
> at org.jboss.as.cli.embedded.ThreadContextsModelControllerClient.execute(ThreadContextsModelControllerClient.java:59)
> at org.jboss.as.cli.handlers.batch.BatchRunHandler.doHandle(BatchRunHandler.java:91)
> at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:88)
> at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:776)
> at org.jboss.as.cli.impl.CommandContextImpl.handleSafe(CommandContextImpl.java:799)
> at org.jboss.as.cli.impl.CliLauncher.processFile(CliLauncher.java:334)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:262)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:45)
> 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.modules.Module.run(Module.java:329)
> at org.jboss.modules.Main.main(Main.java:507)
> {code}
> Java Bug Overview:
> https://bugs.openjdk.java.net/browse/JDK-8165852
> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u...
> Wildfly Stack Overflow issue, not solved:
> https://stackoverflow.com/questions/41022393/mount-point-not-found
> Background Info:
> http://mail.openjdk.java.net/pipermail/nio-dev/2016-October/003915.html
> A) chroot environment [1]
> B) Docker container with overlay and overlay2 storage drivers [2]
> C) btrfs file system with an unmounted sub-volume [2]
> [1] https://bugs.openjdk.java.net/browse/JDK-8165323 - cannot get FileStore in chroot environment
> [2] https://bugs.openjdk.java.net/browse/JDK-8165852 - cannot get FileStore for a file in overlayfs in Docker
> Docker file system/storage driver:
> https://docs.docker.com/engine/userguide/storagedriver/selectadriver/)
> Yum yum-plugin-ovl, similar problem:
> https://github.com/CentOS/sig-cloud-instance-images/issues/15
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months