[JBoss JIRA] (JGRP-1742) BARRIER: minimize closing time
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1742?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1742:
--------------------------------
OK, so the following things might solve this puzzle:
h5. Coordinator blocked during fetching of digest
* Since BARRIER is closed during a state transfer, the coordinator will not only drop messages from other members (except from members for which holes were punched into BARRIER), but also *from itself*
* Currently, the only message that causes problems when dropped is a VIEW change multicast
* SOLUTION: when multicasting a view V, *have the coord install V locally before multicasting it*. When receiving V, it will get dropped as it is already installed
h5. BARRIER skips threads in BLOCKED or WAITING state
* Don't skip these, as a blocked thread might simply block on a lock, before changing state (e.g. Infinispan)
* If message P:10 was blocked, and we skipped it when fetching the digest, we'd include P:10 in the digest, but not in the state. This would mean that the state requester will never get P:10, neither as part of the state, nor as a retransmission from P
h5. Flushing of threads in BARRIER should time out
* We cannot wait forever for the threads to time out
* The timeout passed to {{getState(timeout)}} should be used to bound the max duration for flushing the threads
* A timeout of 0 means wait forever
* Closing the channel should terminate the flush
> BARRIER: minimize closing time
> ------------------------------
>
> Key: JGRP-1742
> URL: https://issues.jboss.org/browse/JGRP-1742
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> During a state transfer, BARRIER.up() waits until all incoming threads (delivering messages to the application) are done, and blocks further incoming messages. This is done to get the digest and the state.
> However, duing the block, the following messages are not sent up:
> * Views !
> * STABLE messages, triggering retransmissions
> This is bad, so we should try to minimize the time BARRIER is closed. This can be done with JGRP-1352.
> However, we could also do the following:
> * A state request is received
> * Close BARRIER and flush all pending threads. This ensures that any message which updated the *digest* also updated the *application state*
> * Get the digest D
> * *Open* BARRIER. Messages will now be delivered and thus applied to the state
> * Get the application state S
> * When done, return D and S to the state requester
> The difference to JGRP-1352 is that we don't queue messages during state transfer. How does this work ? It is critical to ensure that all mesages which updated the digest D also updated the state S, or else messages present in D but not in S would not be retransmitted. However, if there are more messages in S than in D, this is not an issue as they will be retransmitted again.
> Example:
> * BARRIER is closed and pending threads are flushed
> * Digest D is (only for a given member P) 5, state S is 5 as well
> * Now we open BARRIER
> * P sends a few more messages (6, 7 and 8)
> * The digest is now 8, but the copy we have is still 5
> * State S is 8
> * We return D=5 and S=8
> * The state requester closes BARRIER and sets its digest to 5 and its state to 8
> * Since the digest is only 5 for P, the state requester asks P for retransmission of messages 6, 7 and 8
> * Messages 6, 7 and 8 from P are received and applied to the state
> * The assumption here is that if messages 6, 7 and 8 are applied twice, the state doesn't change (idempotency). This should be the case with Infinispan.
> The advantage of this issue over JGRP-1352 is that we don't need to queue messages for a long time if the state is large.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (SECURITY-771) Enable white-space in parameters for external password command
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/SECURITY-771?page=com.atlassian.jira.plug... ]
Ivo Studensky updated SECURITY-771:
-----------------------------------
Attachment: (was: SECURITY-771.patch)
> Enable white-space in parameters for external password command
> --------------------------------------------------------------
>
> Key: SECURITY-771
> URL: https://issues.jboss.org/browse/SECURITY-771
> Project: PicketBox
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: JBossSX
> Affects Versions: PicketBox_4_0_19.Final
> Reporter: Ivo Studensky
> Assignee: Peter Skopek
> Attachments: SECURITY-771_2.patch
>
>
> The current implementation of the loading the external password by a command uses Runtime.exec() which denies to pass a parameter which contains a white-space to the command, see {{\{EXT\}}} in org.jboss.security.Util#loadPassword(String).
> It would be nice to provide a new implementation based on ProcessBuilder.
> For example, various ssh-askpass implementations requires a parameter like 'Enter passphrase for ...'. Without the ability to directly pass such a parameter customers are pushed to create a "script in the middle" which makes their application unnecessarily complicated.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (SECURITY-771) Enable white-space in parameters for external password command
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/SECURITY-771?page=com.atlassian.jira.plug... ]
Ivo Studensky updated SECURITY-771:
-----------------------------------
Attachment: SECURITY-771_2.patch
Updated the patch with {{org.jboss.security.Util#isPasswordCommand(char[])}}.
> Enable white-space in parameters for external password command
> --------------------------------------------------------------
>
> Key: SECURITY-771
> URL: https://issues.jboss.org/browse/SECURITY-771
> Project: PicketBox
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: JBossSX
> Affects Versions: PicketBox_4_0_19.Final
> Reporter: Ivo Studensky
> Assignee: Peter Skopek
> Attachments: SECURITY-771_2.patch
>
>
> The current implementation of the loading the external password by a command uses Runtime.exec() which denies to pass a parameter which contains a white-space to the command, see {{\{EXT\}}} in org.jboss.security.Util#loadPassword(String).
> It would be nice to provide a new implementation based on ProcessBuilder.
> For example, various ssh-askpass implementations requires a parameter like 'Enter passphrase for ...'. Without the ability to directly pass such a parameter customers are pushed to create a "script in the middle" which makes their application unnecessarily complicated.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (DROOLS-266) KIE resolving dependend artifacts issue
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-266?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-266:
------------------------------------------------
Tomas David <tdavid(a)redhat.com> changed the Status of [bug 1014157|https://bugzilla.redhat.com/show_bug.cgi?id=1014157] from ON_QA to VERIFIED
> KIE resolving dependend artifacts issue
> ---------------------------------------
>
> Key: DROOLS-266
> URL: https://issues.jboss.org/browse/DROOLS-266
> Project: Drools
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.CR3
> Reporter: Kurt Stam
> Assignee: Mario Fusco
> Fix For: 6.0.0.CR5
>
> Attachments: kie-load-from-maven-issue.tgz, kie-load-from-maven-issue.tgz
>
>
> This happens when for a dependency the scope is
> - set to 'provided' and
> - a parameter (in the case ${jbpm.version}) is used in the version field.
> So the relevant entry in the pom is:
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>drools-core</artifactId>
> <version>${drools.version}</version>
> <scope>provided</scope>
> </dependency>
> which leads to
> 11:15:02,584 WARN Dependency artifact not found for: org.jbpm:jbpm-bpmn2:${jbpm.version}
> and then the NPE. I'm guessing the parameter is not being resolved.
> 1. it probably should resolve parameters
> 2. if a dependency is scoped as 'provided' I think it is supposed to locate it on the classpath and NOT from maven. However I'm not sure this is the way that works in testing anyway.
> 3. if the dependency cannot be found it should probably stop and not even proceed rather then warn?
> 4. it should be interesting to see why it gets the NPE.
> If you change the dependency from 'provided' to 'test' things work fine.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (WFLY-2605) TCCL leak in infinispan transaction reaper thread
by Brent Douglas (JIRA)
Brent Douglas created WFLY-2605:
-----------------------------------
Summary: TCCL leak in infinispan transaction reaper thread
Key: WFLY-2605
URL: https://issues.jboss.org/browse/WFLY-2605
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering, JPA / Hibernate
Affects Versions: 8.0.0.Beta1
Environment: Fedora 19, Oracle 7u45, Wildfly 7952aa65e67e1d
Reporter: Brent Douglas
Assignee: Paul Ferraro
The reaper thread created in TransactionTable is leaking a deployment module classloader. I have observed by deploying and undeploying the same artifact a couple of times over that only the first deployment is held.
Looking at where the thread is created in [TransactionTable|https://github.com/infinispan/infinispan/blob/master/cor...] it looks to me like it will get the TCCL of the caller so either that should be changed in Infinispan or the caller TCCL should be set appropriately.
!http://i.imgur.com/M37pHSe.png!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (WFLY-2329) File upload doesn't work
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/WFLY-2329?page=com.atlassian.jira.plugin.... ]
Tomas Remes commented on WFLY-2329:
-----------------------------------
Well to be precise, it does work fine, until you explicitly specify FacesServlet definition in your web.xml ( If I understand it correctly, it means that you don't use the default configuration for 3.0, therefore you should also specify the multipart-config element in this case). So it's likely fixed, or WDYT?
> File upload doesn't work
> ------------------------
>
> Key: WFLY-2329
> URL: https://issues.jboss.org/browse/WFLY-2329
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JSF, Web (JBoss Web)
> Affects Versions: 8.0.0.Beta1
> Environment: - Windows 7 64
> - Wildfly Beta 1
> - JSF Mojarra 2.2.3
> - Primefaces 4.0
> - Apache commons-io-2.4 & commons-fileupload-1.3
> Reporter: Domen Cebulj
> Assignee: Stuart Douglas
> Labels: fileUpload, jsf22, primefaces, servlet
> Fix For: 8.0.0.CR1
>
> Attachments: fileUpload.war
>
>
> In the previous version it worked, but in Beta 1 stopped worked file uploading with PF4 and Mojarra 2.2.3 (neither simple upload didn't work - tested on blank project, only with PF4 and Apache libs and configured web.xml file)
> I get no error in IDE or JS console.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (WFLY-2603) The CLI should be capable of updating/adding/removing indivisual items in a list
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2603?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar closed WFLY-2603.
-----------------------------
Assignee: Tomaz Cerar (was: Alexey Loubyansky)
Resolution: Duplicate Issue
Duplicate of WFLY-548
> The CLI should be capable of updating/adding/removing indivisual items in a list
> --------------------------------------------------------------------------------
>
> Key: WFLY-2603
> URL: https://issues.jboss.org/browse/WFLY-2603
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: CLI
> Affects Versions: 8.0.0.Beta1
> Environment: WildFly current build
> Reporter: Tom Fonteyne
> Assignee: Tomaz Cerar
>
> Here is an example using a security domain. The issue is of course valid for all locations where a list of objects is expected.
> (for brevity, I only list a couple of options)
> /subsystem=security/security-domain=LdapRealm:add(cache-type=default)
> /subsystem=security/security-domain=LdapRealm/authentication=classic:add(login-modules=[{"code" => "LdapExtended", "flag" => "required", "module-options" => {"java.naming.provider.url" => "ldap://server.redhat.com:389/", "roleRecursion" => "0" }}])
> There is currently no way to change a *single* option in that list. You can only remove the attribute "module-options" completely and re-add it.
> We need something like:
> /subsystem=security/security-domain=LdapRealm/authentication=classic/login-module=LdapExtended:write-list-attribute(name=module-options,value={"roleRecursion" => "1"})
> and similarly for "read" and "undefine" methods
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (WFLY-2603) The CLI should be capable of updating/adding/removing indivisual items in a list
by Tom Fonteyne (JIRA)
Tom Fonteyne created WFLY-2603:
----------------------------------
Summary: The CLI should be capable of updating/adding/removing indivisual items in a list
Key: WFLY-2603
URL: https://issues.jboss.org/browse/WFLY-2603
Project: WildFly
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: CLI
Affects Versions: 8.0.0.Beta1
Environment: WildFly current build
Reporter: Tom Fonteyne
Assignee: Alexey Loubyansky
Here is an example using a security domain. The issue is of course valid for all locations where a list of objects is expected.
(for brevity, I only list a couple of options)
/subsystem=security/security-domain=LdapRealm:add(cache-type=default)
/subsystem=security/security-domain=LdapRealm/authentication=classic:add(login-modules=[{"code" => "LdapExtended", "flag" => "required", "module-options" => {"java.naming.provider.url" => "ldap://server.redhat.com:389/", "roleRecursion" => "0" }}])
There is currently no way to change a *single* option in that list. You can only remove the attribute "module-options" completely and re-add it.
We need something like:
/subsystem=security/security-domain=LdapRealm/authentication=classic/login-module=LdapExtended:write-list-attribute(name=module-options,value={"roleRecursion" => "1"})
and similarly for "read" and "undefine" methods
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (WFLY-2604) The CLI should be capable of updating/adding/removing indivisual items in a list
by Tom Fonteyne (JIRA)
Tom Fonteyne created WFLY-2604:
----------------------------------
Summary: The CLI should be capable of updating/adding/removing indivisual items in a list
Key: WFLY-2604
URL: https://issues.jboss.org/browse/WFLY-2604
Project: WildFly
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: CLI
Affects Versions: 8.0.0.Beta1
Environment: WildFly current build
Reporter: Tom Fonteyne
Assignee: Alexey Loubyansky
Here is an example using a security domain. The issue is of course valid for all locations where a list of objects is expected.
(for brevity, I only list a couple of options)
/subsystem=security/security-domain=LdapRealm:add(cache-type=default)
/subsystem=security/security-domain=LdapRealm/authentication=classic:add(login-modules=[{"code" => "LdapExtended", "flag" => "required", "module-options" => {"java.naming.provider.url" => "ldap://server.redhat.com:389/", "roleRecursion" => "0" }}])
There is currently no way to change a *single* option in that list. You can only remove the attribute "module-options" completely and re-add it.
We need something like:
/subsystem=security/security-domain=LdapRealm/authentication=classic/login-module=LdapExtended:write-list-attribute(name=module-options,value={"roleRecursion" => "1"})
and similarly for "read" and "undefine" methods
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months