[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 edited comment on JGRP-1742 at 12/4/13 9:26 AM:
---------------------------------------------------------
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. If we run into a timeout, either at the state requester or the provider, state transfer (the {{getState()}}) call will fail
* A timeout of 0 means wait forever
* Closing the channel should terminate the flush
h5. Things not tackled
* While flushing of threads might succeed in BARRIER, if the application has its own thread pool (e.g. using the _Asynchronous Invocation API_) to handle requests, then flushing will return quickly
* However, this is not a guarantee that all incoming threads have completed their changes to the application state
* A possible solution might be to call the {{block()}} and {{unblock()}} callbacks in the application. The former would have to wait until all current threads are done modifying the application state. The latter would be called when the digest has been fetched and the application pool can continue making modifications.
** Not very nice, but state transfer should not be used for very large states (taking a long time) anyway
** This will not be addressed by this JIRA. Perhaps it will be tackled in a later release.
was (Author: belaban):
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
10 years, 7 months
[JBoss JIRA] (WFLY-164) java.io.IOException Channel closed exception after several reload of server
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-164?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on WFLY-164:
----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1006246|https://bugzilla.redhat.com/show_bug.cgi?id=1006246] from MODIFIED to ON_QA
> java.io.IOException Channel closed exception after several reload of server
> ---------------------------------------------------------------------------
>
> Key: WFLY-164
> URL: https://issues.jboss.org/browse/WFLY-164
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Ondřej Chaloupka
> Assignee: Emanuel Muckenhuber
> Fix For: 8.0.0.Alpha1
>
>
> Small testing program:
> https://github.com/ochaloup/jboss-dmr-test/blob/master/src/main/java/ocha...
> When I run it first time then everything is fine and reload is done and info from server is shown.
> When I left the server run and execute my program several more times (3 or more) then it's starting to crash with exception
> {code}
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: java.io.IOException: java.util.concurrent.ExecutionException: Operation failed
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> at ochaloup.ClientReload.main(ClientReload.java:19)
> ... 6 more
> Caused by: java.util.concurrent.ExecutionException: Operation failed
> at org.jboss.threads.AsyncFutureTask.operationFailed(AsyncFutureTask.java:74)
> at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:268)
> at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> ... 8 more
> Caused by: java.io.IOException: Channel closed
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleChannelClosed(AbstractMessageHandler.java:354)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient$2.handleClose(RemotingModelControllerClient.java:135)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient$2.handleClose(RemotingModelControllerClient.java:132)
> at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing$3.handleClose(ManagementClientChannelStrategy.java:189)
> at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing$3.handleClose(ManagementClientChannelStrategy.java:180)
> at org.jboss.remoting3.spi.SpiUtils.safeHandleClose(SpiUtils.java:54)
> at org.jboss.remoting3.spi.AbstractHandleableCloseable$CloseHandlerTask.run(AbstractHandleableCloseable.java:501)
> at org.jboss.remoting3.spi.AbstractHandleableCloseable.runCloseTask(AbstractHandleableCloseable.java:406)
> at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeComplete(AbstractHandleableCloseable.java:277)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:517)
> at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359)
> at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:382)
> at org.jboss.remoting3.remote.RemoteConnectionHandler.handleConnectionClose(RemoteConnectionHandler.java:103)
> at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:78)
> at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:45)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
> at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
> at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
> at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
> at org.xnio.ssl.JsseConnectedSslStreamChannel.handleReadable(JsseConnectedSslStreamChannel.java:180)
> at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
> at org.xnio.nio.NioHandle.run(NioHandle.java:90)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
> {code}
> Maybe this could be connected with AS7 testsuite problem:
> https://issues.jboss.org/browse/AS7-4185
--
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
10 years, 7 months
[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
10 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
10 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
10 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
10 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
10 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
10 years, 7 months