[JBoss JIRA] (JGRP-1821) SEQUENCER2: new impl of total order protocol
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1821?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1821:
---------------------------
Fix Version/s: 4.1
(was: 3.5)
> SEQUENCER2: new impl of total order protocol
> --------------------------------------------
>
> Key: JGRP-1821
> URL: https://issues.jboss.org/browse/JGRP-1821
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.1
>
>
> When in {{SEQUENCER}} a member P wants to send a multicast message M, it unicasts it to the coordinator, who multicasts it on behalf of P.
> The new impl {{SEQUENCER2}} is different:
> * P asks the coord for a seqno
> * The coord responds with a (monotonically increasing) seqno
> * P multicasts M with that seqno
> * Everyone uses one global {{Table}} to deliver messages and weed out duplicates
> Advantages:
> # A sender sends messages itself, so the sequencer doesn't need to do sending (and potential retransmissions)
> # Compared to {{SEQUENCER}}, the data is only sent and marshalled once (better for large messages)
> # A sender grabs entire ranges of seqnos, so this should be efficient
> The edge case handling though requires some work, e.g.
> * A member B crashes after having received a seqno (e.g. 4)
> ** The sequencer will give out 5 next, but since nobody received 4, all subsequent messages will get stuck, waiting for 4
> * The sequencer (coord) dies or leaves
> ** The next-in-line probably needs to run some reconciliation protocol, asking all members for their highest received seqnos
> ** Messages like 4 would get marked as dummy, removed from table and dropped
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (JGRP-1680) RDMA based transport
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1680?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1680:
---------------------------
Fix Version/s: 4.1
(was: 4.0)
> RDMA based transport
> --------------------
>
> Key: JGRP-1680
> URL: https://issues.jboss.org/browse/JGRP-1680
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.1
>
>
> Investigate whether an RDMA based transport makes sense.
> Advantages:
> * Speed, low latency (TCP/IP is bypassed entirely)
> * Low CPU usage
> Disadvantages:
> * JNI/C code
> ** Such a transport implementation would have to live outside of the JGroups repo
> ** Maintainability nightmare: the C code would also have to be ported to various OSes
> *** Investigate Java based libs (IBM's jVerbs) and C based libs (Apache Portable Runtime?)
> * High memory use, growing with cluster size: similarly to TCP, a 'group multicast' would involve N-1 sends. RDMA requires a Queue Pair (QP) for each destination. Each QP requires pinned memory (receive and send buffer), so each node would have to reserve (pin) N-1 memory buffers [1]
> ** OTOH, we may not use many group multicasts, e.g. with Infinispan's partial replication (DIST mode)
> * High cost of RDMA adapters, NICs and wiring: only a very small fraction of users would run such a transport.
> [1] http://www.hpcwire.com/hpcwire/2006-08-18/a_critique_of_rdma-1.html
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (JGRP-1424) TP: use of multiple transports
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1424?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1424:
---------------------------
Fix Version/s: 4.1
(was: 4.0)
> TP: use of multiple transports
> ------------------------------
>
> Key: JGRP-1424
> URL: https://issues.jboss.org/browse/JGRP-1424
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.1
>
>
> Refactor TP so that the socket sending and receiving is done in a separate class (UDP, TCP, TCP_NIO). Once this is done, add the ability to attach multiple transports to TP, e.g. UDP and TCP.
> The UDP transport could then be used for cluster wide messages (null destination) and the TCP transport could be used for unicast messages (non-null destination).
> Or this could be overridden by a message flag on a per-message basis !
> We could even attach multiple transports of the same type, e.g. one per physical network (10.x.x.x and 192.168.x.x), and do round-robin sending over them.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 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 updated JGRP-1672:
---------------------------
Fix Version/s: 4.1
(was: 4.0)
> 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
> Fix For: 4.1
>
> 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
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (DROOLS-465) Cannot find KieModule with LATEST
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-465?page=com.atlassian.jira.plugin... ]
Mario Fusco commented on DROOLS-465:
------------------------------------
What suggested by the reporter of this issue (avoiding to add the local repository among the remote ones) actually prevents the maven-metadata.xml file to be removed and fixes this issue. Unfortunately this solution breaks the retrieval of newly deployed SNAPSHOTs while the KieScanner is running.
I'm trying to figure out why and how to fix this problem without breaking SNAPSHOTs resolution.
> Cannot find KieModule with LATEST
> ---------------------------------
>
> Key: DROOLS-465
> URL: https://issues.jboss.org/browse/DROOLS-465
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Beta1
> Reporter: Takami Hirata
> Assignee: Mario Fusco
> Attachments: reproducer.zip
>
>
> I install a kmodule into local repository with command {{mvn clean install}}.
> Loading this kmodule with 'LATEST' works on the day, but will fail on next day.
> Maven will find update on next day because of default updatePolicy 'daily', then maven check local repository ({{org.kie.scanner.Aether}} treats as a remote repository) but local artifact cache does not have 'maven-metadata.xml' which remote artifact should have, so finding update fails and {{org.sonatype.aether.connector.file.FileRepositoryWorker}} removes {{maven-metadata-local.xml}} for cleanup.
> {{org.kie.scanner.Aether}} adds local repository to remote repositories, but this may be incorrect usage.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (DROOLS-465) Cannot find KieModule with LATEST
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-465?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-465:
------------------------------------------------
Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1303018|https://bugzilla.redhat.com/show_bug.cgi?id=1303018] from NEW to ASSIGNED
> Cannot find KieModule with LATEST
> ---------------------------------
>
> Key: DROOLS-465
> URL: https://issues.jboss.org/browse/DROOLS-465
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Beta1
> Reporter: Takami Hirata
> Assignee: Mario Fusco
> Attachments: reproducer.zip
>
>
> I install a kmodule into local repository with command {{mvn clean install}}.
> Loading this kmodule with 'LATEST' works on the day, but will fail on next day.
> Maven will find update on next day because of default updatePolicy 'daily', then maven check local repository ({{org.kie.scanner.Aether}} treats as a remote repository) but local artifact cache does not have 'maven-metadata.xml' which remote artifact should have, so finding update fails and {{org.sonatype.aether.connector.file.FileRepositoryWorker}} removes {{maven-metadata-local.xml}} for cleanup.
> {{org.kie.scanner.Aether}} adds local repository to remote repositories, but this may be incorrect usage.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6097) Error response handling from bean validation ignores Accept header
by Gunnar Morling (JIRA)
[ https://issues.jboss.org/browse/WFLY-6097?page=com.atlassian.jira.plugin.... ]
Gunnar Morling commented on WFLY-6097:
--------------------------------------
Ah, it appears that you are running into RESTEASY-1264. This is only triggered if the JAX-RS resource is a CDI bean (I head tried it with an EJB originally which is why I couldn't reproduce it). That issue also describes a possible work-around for the time being.
> Error response handling from bean validation ignores Accept header
> ------------------------------------------------------------------
>
> Key: WFLY-6097
> URL: https://issues.jboss.org/browse/WFLY-6097
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Environment: Mac OS X El Captain
> java version "1.8.0_66"
> Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)
> Reporter: Renann Prado
> Assignee: Jason Greene
> Attachments: delivery-optimization-ear-1.0.Final.ear
>
>
> Basically I have a very simple application that has request validation in the REST endpoints.
> According to the documentation of RESTEasy, I should get a JSON error response if I put "application/json" in Accept header in the request.
> https://docs.jboss.org/resteasy/docs/3.0.13.Final/userguide/html/Validati...
> The mentioned feature worked just fine in Wildfly 9.0.2.Final. Now, however, it doesn't.
> I have tried to upgrade the dependencies in the pom.xml to use dependencies from Wildfly 10.0.0.Final, but still no luck. Though the attached application deploys just fine in Wildfly 9.0.2.Final and Wildfly 10.0.0.Final.
> In WF 9.0.2.Final I used to get the below error *JSON*
> {code:json}
> {
> "exception": null,
> "fieldViolations": [],
> "propertyViolations": [],
> "classViolations": [],
> "parameterViolations": [{
> "constraintType": "PARAMETER",
> "path": "registerLogisticsNetwork.arg0.name",
> "message": "may not be null",
> "value": ""
> }],
> "returnValueViolations": []
> }
> {code}
> In WF 10.0.0.Final I get this:
> {code}
> [PARAMETER]
> [registerLogisticsNetwork.arg0.name]
> [may not be null]
> []
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6097) Error response handling from bean validation ignores Accept header
by Gunnar Morling (JIRA)
[ https://issues.jboss.org/browse/WFLY-6097?page=com.atlassian.jira.plugin.... ]
Gunnar Morling commented on WFLY-6097:
--------------------------------------
Can you attach the sources of a simple example (e.g. without database interactions) and your invocation of the REST endpoint, please? Maybe you are not specifying the accept header correctly.
It works as expected for me, when specifying the request header "Accept: application/json", I'll get back a JSON response, otherwise the plain text representation (the -1 in the payload is violating a constraint of my example service):
{code}
curl -XPOST <MY_URL> -H "Content-Type: application/json" -H "Accept: application/json" -d '-1'
{code}
{code}
{"exception":null,"fieldViolations":[],"propertyViolations":[],"classViolations":[],"parameterViolations":[{"constraintType":"PARAMETER","path":"test.arg0","message":"must be greater than or equal to 1","value":"-1"}],"returnValueViolations":[]}%
{code}
> Error response handling from bean validation ignores Accept header
> ------------------------------------------------------------------
>
> Key: WFLY-6097
> URL: https://issues.jboss.org/browse/WFLY-6097
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Environment: Mac OS X El Captain
> java version "1.8.0_66"
> Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)
> Reporter: Renann Prado
> Assignee: Jason Greene
> Attachments: delivery-optimization-ear-1.0.Final.ear
>
>
> Basically I have a very simple application that has request validation in the REST endpoints.
> According to the documentation of RESTEasy, I should get a JSON error response if I put "application/json" in Accept header in the request.
> https://docs.jboss.org/resteasy/docs/3.0.13.Final/userguide/html/Validati...
> The mentioned feature worked just fine in Wildfly 9.0.2.Final. Now, however, it doesn't.
> I have tried to upgrade the dependencies in the pom.xml to use dependencies from Wildfly 10.0.0.Final, but still no luck. Though the attached application deploys just fine in Wildfly 9.0.2.Final and Wildfly 10.0.0.Final.
> In WF 9.0.2.Final I used to get the below error *JSON*
> {code:json}
> {
> "exception": null,
> "fieldViolations": [],
> "propertyViolations": [],
> "classViolations": [],
> "parameterViolations": [{
> "constraintType": "PARAMETER",
> "path": "registerLogisticsNetwork.arg0.name",
> "message": "may not be null",
> "value": ""
> }],
> "returnValueViolations": []
> }
> {code}
> In WF 10.0.0.Final I get this:
> {code}
> [PARAMETER]
> [registerLogisticsNetwork.arg0.name]
> [may not be null]
> []
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-5343) Datasource configuration allows editing driver name to non-existing one
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-5343?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski closed WFLY-5343.
------------------------------------
Resolution: Won't Fix
Designed this way. Activation phase does all checks.
> Datasource configuration allows editing driver name to non-existing one
> -----------------------------------------------------------------------
>
> Key: WFLY-5343
> URL: https://issues.jboss.org/browse/WFLY-5343
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Reporter: Jan Kašík
> Assignee: Bartosz Baranowski
>
> When editing datasource attributes, JDBC driver name can be changed to driver which is not installed (deployed) without any error message being showed. Although error message "A driver needs to be specified or chosen!" is showed if driver, which is not present in system, is filled in form during addition of new datasource.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months