[JBoss JIRA] (WFLY-8335) User should be informed when switching between JDBC and journal store in transactions subsystem
by Romain Pelisse (JIRA)
[ https://issues.jboss.org/browse/WFLY-8335?page=com.atlassian.jira.plugin.... ]
Romain Pelisse commented on WFLY-8335:
--------------------------------------
[~claudio4j] Yep, I understood why did the batch, and this is also why I add a specific test, in my PR, using the CLI batch. However, I could not reproduce the issue with batch. In my case (as shown above) the batch is failing properly, complaining that one can not use both JDBC and Journal store.
Can you try rebuilding Widlfly with my PR and let me know if you can reproduce the issue (2) ?
> User should be informed when switching between JDBC and journal store in transactions subsystem
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-8335
> URL: https://issues.jboss.org/browse/WFLY-8335
> Project: WildFly
> Issue Type: Enhancement
> Components: Transactions
> Affects Versions: 10.1.0.Final
> Reporter: Romain Pelisse
> Assignee: Romain Pelisse
> Priority: Minor
> Fix For: 11.0.0.Beta1
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> Precondition: 'Use journal store' or 'Use JDBC store' was previously set to true.
> When enabling other type of store, user is not informed about the fact, that only one of those can be set and the previously enabled store is disabled and the new store is enabled without notification. User should be definitely informed about this.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8744) The exception should be able to return to client if retry is 0 with ws-rm
by Petr Jurak (JIRA)
[ https://issues.jboss.org/browse/WFLY-8744?page=com.atlassian.jira.plugin.... ]
Petr Jurak deleted WFLY-8744:
-----------------------------
> The exception should be able to return to client if retry is 0 with ws-rm
> -------------------------------------------------------------------------
>
> Key: WFLY-8744
> URL: https://issues.jboss.org/browse/WFLY-8744
> Project: WildFly
> Issue Type: Bug
> Reporter: Petr Jurak
> Assignee: Alessio Soldano
>
> CXF-2841 fix the scenario that when the ws-rm retransmission kick in the exception occured in client out interceptor shouldn't return to client. However, there's case that ws-rm retry set as 0 like
> SourcePolicyType sourcePolicy = new SourcePolicyType();
> RetryPolicyType retryP = new RetryPolicyType();
> retryP.setMaxRetries(0);
> sourcePolicy.setRetryPolicy(retryP);
> bus.getExtension(RMManager.class).setSourcePolicy(sourcePolicy);
> In this case the exception should be able to return to client so that the client can fast fail.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8744) The exception should be able to return to client if retry is 0 with ws-rm
by Petr Jurak (JIRA)
Petr Jurak created WFLY-8744:
--------------------------------
Summary: The exception should be able to return to client if retry is 0 with ws-rm
Key: WFLY-8744
URL: https://issues.jboss.org/browse/WFLY-8744
Project: WildFly
Issue Type: Bug
Components: Web Services
Reporter: Petr Jurak
Assignee: Alessio Soldano
CXF-2841 fix the scenario that when the ws-rm retransmission kick in the exception occured in client out interceptor shouldn't return to client. However, there's case that ws-rm retry set as 0 like
SourcePolicyType sourcePolicy = new SourcePolicyType();
RetryPolicyType retryP = new RetryPolicyType();
retryP.setMaxRetries(0);
sourcePolicy.setRetryPolicy(retryP);
bus.getExtension(RMManager.class).setSourcePolicy(sourcePolicy);
In this case the exception should be able to return to client so that the client can fast fail.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8335) User should be informed when switching between JDBC and journal store in transactions subsystem
by Claudio Miranda (JIRA)
[ https://issues.jboss.org/browse/WFLY-8335?page=com.atlassian.jira.plugin.... ]
Claudio Miranda commented on WFLY-8335:
---------------------------------------
Hi Romain, thanks for the fix. HAL uses composite operation to write several attributes, when users changes it in the form, so the cli batch operation is a way to reproduce the issue.
> User should be informed when switching between JDBC and journal store in transactions subsystem
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-8335
> URL: https://issues.jboss.org/browse/WFLY-8335
> Project: WildFly
> Issue Type: Enhancement
> Components: Transactions
> Affects Versions: 10.1.0.Final
> Reporter: Romain Pelisse
> Assignee: Romain Pelisse
> Priority: Minor
> Fix For: 11.0.0.Beta1
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> Precondition: 'Use journal store' or 'Use JDBC store' was previously set to true.
> When enabling other type of store, user is not informed about the fact, that only one of those can be set and the previously enabled store is disabled and the new store is enabled without notification. User should be definitely informed about this.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-5169) "XNIO001001: No XNIO provider found" by some tests in main TS with security manager
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-5169?page=com.atlassian.jira.plugin.... ]
Ivo Studensky reassigned WFLY-5169:
-----------------------------------
Assignee: Ivo Studensky (was: Josef Cacek)
> "XNIO001001: No XNIO provider found" by some tests in main TS with security manager
> -----------------------------------------------------------------------------------
>
> Key: WFLY-5169
> URL: https://issues.jboss.org/browse/WFLY-5169
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Marek Kopecký
> Assignee: Ivo Studensky
>
> *Description*
> Some tests in wildfly fails due to "XNIO001001: No XNIO provider found" while run with security manager enabled. Similar jira for wildfly-core:
> * https://issues.jboss.org/browse/JBEAP-530
> *Affected tests found so far:*
> * org.jboss.as.test.integration.ejb.mdb.MDBTestCase#testSuspendResumeWithMDB
> * org.jboss.as.test.integration.ejb.mdb.deliveryactive.MDBTestCase#testDeliveryActiveWithAnnotation
> * org.jboss.as.test.integration.ejb.mdb.deliveryactive.MDBTestCase#testDeliveryActiveWithDeploymentDescriptor
> * org.jboss.as.test.integration.batch.chunk.ChunkPartitionTestCase#testSuspend
> * org.jboss.as.test.integration.batch.deployment.JobControlTestCase#testStart
> * org.jboss.as.test.integration.ee.concurrent.EEConcurrentManagementTestCase#testContextServiceManagement
> * org.jboss.as.test.integration.ee.concurrent.EEConcurrentManagementTestCase#testManagedThreadFactoryManagement
> * org.jboss.as.test.integration.ee.concurrent.EEConcurrentManagementTestCase#testManagedExecutorServiceManagement
> * org.jboss.as.test.integration.ee.concurrent.EEConcurrentManagementTestCase#testManagedScheduledExecutorServiceManagement
> * org.jboss.as.test.integration.ejb.timerservice.suspend.TimerServiceSuspendTestCase#testIntervalTimersDoNotBackUp
> * org.jboss.as.test.integration.ejb.timerservice.suspend.TimerServiceSuspendTestCase#testSingleActionTimerWhenSuspended
> * org.jboss.as.test.integration.ejb.timerservice.suspend.TimerServiceSuspendTestCase#testSuspendWithIntervalTimer
> * org.jboss.as.test.integration.jca.capacitypolicies.DatasourceCapacityPoliciesTestCase#testNonDefaultDecrementerAndIncrementer
> * org.jboss.as.test.integration.jca.capacitypolicies.ResourceAdapterCapacityPoliciesTestCase#testNonDefaultDecrementerAndIncrementer
> * org.jboss.as.test.integration.jca.capacitypolicies.XADatasourceCapacityPoliciesTestCase#testNonDefaultDecrementerAndIncrementer
> *Steps to reporoduce MDBTestCase*
> # ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2 -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=MDBTestCase
> *Actual results:*
> {noformat}
> Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.394 sec <<< FAILURE! - in org.jboss.as.test.integration.ejb.mdb.MDBTestCase
> testSuspendResumeWithMDB(org.jboss.as.test.integration.ejb.mdb.MDBTestCase) Time elapsed: 0.19 sec <<< ERROR!
> java.io.IOException: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found
> at org.xnio.Xnio.doGetInstance(Xnio.java:238)
> at org.xnio.Xnio.getInstance(Xnio.java:193)
> at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:112)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:122)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:65)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:147)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:122)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75)
> at org.jboss.as.test.integration.ejb.mdb.MDBTestCase.testSuspendResumeWithMDB(MDBTestCase.java:173)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8743) The exception should be able to return to client if retry is 0 with ws-rm
by Petr Jurak (JIRA)
Petr Jurak created WFLY-8743:
--------------------------------
Summary: The exception should be able to return to client if retry is 0 with ws-rm
Key: WFLY-8743
URL: https://issues.jboss.org/browse/WFLY-8743
Project: WildFly
Issue Type: Bug
Components: Web Services
Reporter: Petr Jurak
Assignee: Alessio Soldano
CXF-2841 fix the scenario that when the ws-rm retransmission kick in the exception occured in client out interceptor shouldn't return to client. However, there's case that ws-rm retry set as 0 like
SourcePolicyType sourcePolicy = new SourcePolicyType();
RetryPolicyType retryP = new RetryPolicyType();
retryP.setMaxRetries(0);
sourcePolicy.setRetryPolicy(retryP);
bus.getExtension(RMManager.class).setSourcePolicy(sourcePolicy);
In this case the exception should be able to return to client so that the client can fast fail.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ELY-1149) Default CS implementation KeyStoreCredentialStore doesn't validate implementation properties
by Martin Choma (JIRA)
Martin Choma created ELY-1149:
---------------------------------
Summary: Default CS implementation KeyStoreCredentialStore doesn't validate implementation properties
Key: ELY-1149
URL: https://issues.jboss.org/browse/ELY-1149
Project: WildFly Elytron
Issue Type: Bug
Reporter: Martin Choma
Assignee: Darran Lofthouse
Priority: Critical
I am able to pass any property into default KeyStoreCredentialStore implementation of credential store. I understand implementation-properties is general data holder for any implementation, so validation can't be made on subsystem level. But each delivered implementation knows which parameters are allowed for itself and thus should check it.
{code}
/subsystem=elytron/credential-store=test:add(relative-to=jboss.server.data.dir,credential-reference={clear-text="pass123+"},implementation-properties={DOES_NOT_EXIST=anything},create=true,location=keystore.jks,modifiable=true)
{code}
It can prevent user from typo error. Also can help user to understand what is allowed for current implementation, as allowed properties can't be describe in model, because resource is for general usage.
{code}
"implementation-properties" => {
"type" => OBJECT,
"description" => "Map of credentials store implementation specific properties.",
"attribute-group" => "implementation",
"expressions-allowed" => true,
"required" => false,
"nillable" => true,
"value-type" => STRING,
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "resource-services"
}
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ELY-1148) Wildfly Elytron Tool, Vault command summary output contains MASKed password even when user uses plain-text password.
by Hynek Švábek (JIRA)
Hynek Švábek created ELY-1148:
---------------------------------
Summary: Wildfly Elytron Tool, Vault command summary output contains MASKed password even when user uses plain-text password.
Key: ELY-1148
URL: https://issues.jboss.org/browse/ELY-1148
Project: WildFly Elytron
Issue Type: Bug
Reporter: Hynek Švábek
Assignee: Darran Lofthouse
Priority: Critical
Vault command summary output contains MASKed password even when user uses plain-text password. It is masked through default values of SALT and ITERATION.
There must be at least an information in help that plain-text password will be masked in summary output and as SALT and ITERATION will be used default values.
{code}
java -jar wildfly-elytron-tool.jar vault --enc-dir ./ --keystore server.store --keystore-password secretsecret --location cs012.jceks --alias jboss --summaryVault (enc-dir="./";keystore="server.store") converted to credential store "cs012.jceks"
Vault Conversion summary:
--------------------------------------
Vault Conversion Successful
CLI command to add new credential store:
/subsystem=elytron/credential-store=cs:add(relative-to=jboss.server.data.dir,location="cs012.jceks",implementation-properties={},credential-reference={clear-text="MASK-13KrO2ZNhwNg3UxmIt.02D;12345678;23"})
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (JGRP-2162) Failed to send broadcast when opening the connection
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/JGRP-2162?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on JGRP-2162:
-----------------------------------
[~belaban]:
1. may not be the option (and no documentation does not suggest that you need all nodes in the initial hosts list for proper functionality)
2. works (at least the attached reproducer - haven't tried the flaky tests), though it requires a modification of configuration.
3. ? If TCPPING doesn't work, we shouldn't recommend its use. I would prefer to keep this guy = fix it.
Could you set {{send_cache_on_join}} to true by default for those static protocols?
> Failed to send broadcast when opening the connection
> ----------------------------------------------------
>
> Key: JGRP-2162
> URL: https://issues.jboss.org/browse/JGRP-2162
> Project: JGroups
> Issue Type: Bug
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 4.0.4
>
> Attachments: TcpNio2McastTest.java, infinispan_2.log.gz
>
>
> IRC discussion:
> {quote}
> bela_: Hi Bela, I have a weird failure in one test that seem to be rooted in JGroups. TCP_NIO2 is in charge, and there's a broadcast message to all nodes, but it seems it's not received on the other side.
> <bela_> rvansa: reproducible?
> <rvansa> bela_: it happens when the connection to a node is just being opened: I have added some trace logs and just a moment before writing to the NioConnection.send_buf it was in state "connection pending"
> <rvansa> bela_: sort of, after tens of runs of that test (on my machine) - and I've seen it first time in CI, so it could be
> <bela_> rvansa: NioConnection buffers writes up to a certain extent, then discards anything over the buffer limit
> <bela_> rvansa: max_send_buffers (default: 10). But retransmission should fix this, unless you don’t wait long enough
> <rvansa> bela_: I don't think it should go over the limit
> <rvansa> bela_: the test is not doing anything else, just sending CommitCommand (that should be couple hundred bytes at most) and then waiting
> <rvansa> bela_: according to the traces I've added, Buffers.write returned false when writing the local address, and then true when writing the actual message
> {quote}
> I have been trying to write a reproducer, and found that it's related to the fact that the failing test uses custom (fake) discovery protocol, that doesn't open the connection during startup. In my ~reproducer I had to modify tcp-nio.xml to use TCPPING with only the first node in hosts list (localhost[7800]):
> {code:xml}
> <TCPPING async_discovery="true" initial_hosts="${jgroups.tcpping.initial_hosts:localhost[7800]}" port_range="0"/>
> {code}
> This causes that the physical connection is not opened by discovery. However, the reproducer suffers from (always reproducible) flaw - it does not send the message to third node at all (and the test fails, therefore).
> Note that increasing the timeout in request options does not help.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months