[JBoss JIRA] (DROOLS-3731) DMN UX - More info overlaid on models.
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3731?page=com.atlassian.jira.plugi... ]
Jozef Marko commented on DROOLS-3731:
-------------------------------------
>From my point of view is some panel better that popup, because the error (the explanation what and how failed / didn't pass) can be quite complex. I think content of panel can be reloaded according tot he selected node.
> DMN UX - More info overlaid on models.
> --------------------------------------
>
> Key: DROOLS-3731
> URL: https://issues.jboss.org/browse/DROOLS-3731
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Elizabeth Clayton
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: UX, UXTeam, drools-tools
> Attachments: Test-error.png, Test-errorB.png, download (1).png, download.png
>
>
> As a practitioner, there are situations where I need to show additional information about a model... for instance: test coverage report: I need to draw a model and color code the nodes to show which nodes were executed by tests, or which rows on a DT were a match. Or when I execute a single test, what was the actual value of a given node or expression.
> Note: Maybe in read-only mode with an "overlay" on top of the model the additional metadata information. See process instance diagram design examples.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (JGRP-1672) Shared memory to send message between different processes on the same box
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-1672?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1672:
--------------------------------
More links:
* https://docs.okd.io/latest/dev_guide/shared_memory.html
* https://www.mirantis.com/blog/multi-container-pods-and-container-communic...
> Shared memory to send message between different processes on the same box
> -------------------------------------------------------------------------
>
> Key: JGRP-1672
> URL: https://issues.jboss.org/browse/JGRP-1672
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0
>
> Attachments: ShmTest.java
>
>
> Investigate whether it makes sense to use shared memory to pass messages between processes on the same box. Say if we have A, B and C on box-1 and X, Y, Z on box-2, when A multicasts a message, it could loop it back to itself, place it into shared memory for B and C to read and multicast it to X, Y, Z. The multicast socket could be non-loopback, so box-1 would not receive it.
> Problems:
> * Shared memory in Java can only be done via memory mapped (sequential or random access) files. To pass a lot of messages, something like a ring buffer would have to be created in shared memory
> * Unless we use FileLock, or polling/busy reading, there is no way to know when a producer has written a message into shared memory. We'd therefore have to use a signalling mechanism, probably a small JGroups message, to notify the consumer(s) of new messages.
> ** Alternatively, we could do busy waiting: the producer writes into a memory location when a message is ready to be consumed. Perhaps this memory location can be the number of messages ready to be read. The consumer could busy-wait, and decrement the number of messages read. This variable could be protected by a file lock, so after some amount of busy-waiting, the consumer could go back and do a real wait on the file lock, instead of burning CPU doing busy-waits.
> * For multicast messages, we'd have 1 producer but many consumers. A RingBuffer would not work here, as we don't know when all consumers have read a given message, ie. when to advance the read pointer
> ** As an alternative, we could have one shared memory buffer per member on the same host. This would also cater to unicast messages. However, then we'd use up a lot of memory.
> * How would this work for TCP ? We'd have to send the message to only members which are outside the local box. How do we identify those members ?
> * Message reception: a multicast message received and targetted to all members on the same box could also be placed into shared memory, so everyone on the same box receives it
> ** How would this work for TCP ? E.g. A sending a multicast message M would use shared memory to deliver M to B and C on box-1, but if it sends it to X, Y and Z, then that's unneeded work, as it could send it only to X, which could place it into shared memory for Y and Z to consume M.
> *** We'd have to include the knowledge of 'affinity' into an address
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-11343) Lock is not released when JTS is enabled and a timer is cancelled inside a transaction
by RH Bugzilla Integration (Jira)
[ https://issues.jboss.org/browse/WFLY-11343?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFLY-11343:
------------------------------------------------
Peter Mackay <pmackay(a)redhat.com> changed the Status of [bug 1648762|https://bugzilla.redhat.com/show_bug.cgi?id=1648762] from ON_QA to VERIFIED
> Lock is not released when JTS is enabled and a timer is cancelled inside a transaction
> --------------------------------------------------------------------------------------
>
> Key: WFLY-11343
> URL: https://issues.jboss.org/browse/WFLY-11343
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Environment: EAP 6.4.18
> Reporter: Shaun Appleton
> Assignee: Thomas Jenkinson
> Priority: Major
> Fix For: 15.0.0.Final
>
>
> Description of problem:
> Lock is held by EJB timer (TimerServiceImpl) and in case JTS transaction is cancelled the lock won't be released correctly . This code is the problem:
> https://github.com/wildfly/wildfly/blob/78dee79dd0f49c6cbd2b8db5d8640980f...
> Basically it holds the timer lock until the transaction completes, and then attempts to release it in afterCompletion. The problem is that when JTS is enabled afterCompletion will be called by a seperate thread, which can't call unlock as it is not the owner.
> A simple fix could be to just change the lock to a semaphore, so that the other thread can release it.
> Version-Release number of selected component (if applicable):
> How reproducible:
> Always
> Steps to Reproduce:
> 1. Start a JTA/JTS tx and call an EJB timer inside it
> 2. Make the transaction timeout
> 3. Capture a thread dump and see a thread like below (0a0818b80 is locked object)
> ---------------------------------------------------------------------------------------------------------
> "Incoming-2,RouterPoliciesClusterGroup,svc-3-comecimpolicy-59228 (, payload=52 bytes)" #661 prio=5 os_prio=0 tid=0x00007f5214c2d000 nid=0x1e67 waiting on condition [0x00007f520ac97000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000a0818b80> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Locked ownable synchronizers:
> - <0x00000000ea1f4c48> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> ---------------------------------------------------------------------------------------------------------
> Actual results:
> Lock being held forever
> Expected results:
> Lock getting released
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-232) Deployment fails when Dependencies is empty in a jars manifest
by RH Bugzilla Integration (Jira)
[ https://issues.jboss.org/browse/WFLY-232?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on WFLY-232:
----------------------------------------------
Peter Mackay <pmackay(a)redhat.com> changed the Status of [bug 1539985|https://bugzilla.redhat.com/show_bug.cgi?id=1539985] from ON_QA to VERIFIED
> Deployment fails when Dependencies is empty in a jars manifest
> --------------------------------------------------------------
>
> Key: WFLY-232
> URL: https://issues.jboss.org/browse/WFLY-232
> Project: WildFly
> Issue Type: Enhancement
> Reporter: Gábor Farkas
> Assignee: Stuart Douglas
> Priority: Major
> Fix For: 8.0.0.Alpha1
>
> Attachments: empty-manifest.ear
>
>
> I have a WAR, which produces the following error on deployment:
> Caused by: java.lang.IllegalArgumentException: Empty module specification
> at org.jboss.modules.ModuleIdentifier.fromString(ModuleIdentifier.java:169) [jboss-modules.jar:1.1.1.GA]
> at org.jboss.as.server.deployment.module.ManifestDependencyProcessor.deploy(ManifestDependencyProcessor.java:83) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> ... 5 more
> I found that my WAR contains a jar in WEB-INF/lib that has empty dependencies defined in its manifest. More exactly it's "Dependencies: ", so the colon is followed by a space character before the new line characters. The ManifestDependencyProcessor parses this as one dependency, the name of which is the empty string.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFCORE-4239) WARN if system-property is already set and is being overridden
by RH Bugzilla Integration (Jira)
[ https://issues.jboss.org/browse/WFCORE-4239?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-4239:
-------------------------------------------------
Peter Mackay <pmackay(a)redhat.com> changed the Status of [bug 1654454|https://bugzilla.redhat.com/show_bug.cgi?id=1654454] from ON_QA to VERIFIED
> WARN if system-property is already set and is being overridden
> --------------------------------------------------------------
>
> Key: WFCORE-4239
> URL: https://issues.jboss.org/browse/WFCORE-4239
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Management
> Reporter: Brad Maxwell
> Assignee: Chao Wang
> Priority: Major
> Labels: downstream_dependency
> Fix For: 8.0.0.Beta2, 8.0.0.Final
>
>
> WARN if system-property is already set and is being overridden
> If user sets a system property using the java opts or on the command line and the same system property is defined in the standalone.xml, then the standalone.xml value overrides that passed on the commandline/JAVA_OPTS, a warning would be useful as looking at the logs (and ps), it shows value1 passed on the command line and nothing indicating that the value was changed later.
> JAVA_OPTS="$JAVA_OPTS -Dmy.system.property=value1"
> {code}
> <system-properties>
> <property name="my.system.property" value="value2"/>
> </system-properties>
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months