July 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1665) Enable gc logging function in startup scripts; require env var to enable it

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1665?page=com.atlassian.jira.plugi... ] Tomaz Cerar updated WFCORE-1665: -------------------------------- Summary: Enable gc logging function in startup scripts; require env var to enable it (was: Uncomment gc logging function in startup scripts; require env var to enable it) > Enable gc logging function in startup scripts; require env var to enable it > --------------------------------------------------------------------------- > > Key: WFCORE-1665 > URL: https://issues.jboss.org/browse/WFCORE-1665 > Project: WildFly Core > Issue Type: Task > Components: Scripts > Reporter: Brian Stansberry > Assignee: Tomaz Cerar > Fix For: 3.0.0.Alpha4 > > > Our startup scripts have gc logging functionality specified by EAP6-121 that is commented out by default. > This approach to disabling this function makes it difficult to use these scripts in EAP; see JBEAP-5374. > We should uncomment function this but only enable it if an env var is set. The .conf files core ships will not set this env var. The ones EAP ships can. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2093) Remove Externalizable from Address

by Bela Ban (JIRA)

Bela Ban created JGRP-2093: ------------------------------ Summary: Remove Externalizable from Address Key: JGRP-2093 URL: https://issues.jboss.org/browse/JGRP-2093 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Priority: Minor Fix For: 4.0 This allows us to remove {{writeExternal()}} and {{readExternal()}} from all addresses, plus {{serialVersionUUID}} as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6512) Missing explanation which services failed to start

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6512?page=com.atlassian.jira.plugin.... ] Radoslav Husar closed WFLY-6512. -------------------------------- Resolution: Duplicate Duplicates WFLY-5688. > Missing explanation which services failed to start > -------------------------------------------------- > > Key: WFLY-6512 > URL: https://issues.jboss.org/browse/WFLY-6512 > Project: WildFly > Issue Type: Bug > Components: Server > Affects Versions: 10.0.0.Final > Reporter: Fedor Gavrilov > Assignee: Fedor Gavrilov > > Missing info which services failed to start on server startup > E.g. when I change in mod_cluster subsystem connector reference to invalid one (/subsystem=modcluster/mod-cluster-config=configuration:write-attribute(name=connector, value=invalid), the server fails to start several services without explaining which ones. This is user unfriendly as it creates hard effort to find out what is actually wrong. There should be at least pointed out which services failed to start. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1228) Entry point update halts the rule Engine

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1228?page=com.atlassian.jira.plugi... ] Mario Fusco closed DROOLS-1228. ------------------------------- Resolution: Cannot Reproduce Bug I tried to reproduce what you described with the test case I'm pasting below, but it works for me. If you're still having this issue please create a complete reproducer (maybe reusing part of what I did) attach it to this ticket and reopen the ticket. {code} @Test public void testUpdateDuringFireUntilHalt() throws Exception { String drl = "import " + AtomicInteger.class.getCanonicalName() + ";\n" + "import " + BlockingQueue.class.getCanonicalName() + ";\n" + "global BlockingQueue queue;\n" + "rule R1 when\n" + " $i: Integer(this > 0) \n" + "then " + " delete($i);" + "end\n" + "rule R2 when\n" + " $i: AtomicInteger(get() == 0 || get() == 2) \n" + "then " + " modify($i) { set( $i.get() + 1 ) };" + " queue.put($i);" + "end\n"; final KieSession ksession = new KieHelper().addContent( drl, ResourceType.DRL ) .build() .newKieSession(); BlockingQueue<AtomicInteger> queue = new LinkedBlockingQueue<AtomicInteger>(); ksession.setGlobal("queue", queue); new Thread () { public void run () { ksession.fireUntilHalt(); } }.start(); new Thread () { public void run () { // keep the engine busy for (int i = 1; i < 1000000; i++) { ksession.insert( i ); } } }.start(); AtomicInteger obj = new AtomicInteger(0); FactHandle fh = ksession.insert( obj ); for (int i = 0; i < 2; i++) { AtomicInteger aInt = queue.take(); if (aInt.get() % 2 == 0) { fail(aInt + " should be odd"); } aInt.set(aInt.get()+1); ksession.update( fh, aInt ); } ksession.halt(); assertEquals( 4, obj.get() ); } {code} > Entry point update halts the rule Engine > ---------------------------------------- > > Key: DROOLS-1228 > URL: https://issues.jboss.org/browse/DROOLS-1228 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Environment: Linux, JBOSS 6.3 EAP, Java 8, Drools 6.2 > Reporter: mithun singh > Assignee: Mario Fusco > Priority: Blocker > Attachments: structure.png > > > 1. A Stateful session is created. > 2. Facts are loaded to stateful session and after successful loading into session we initiate "*fireUntilHault()*" inorder to fire the rules, where we have about 38 rules. > 3. We have configured a queue inorder to receive messages from source system and load the relevant facts into the session by retrieving the entry point from the session, update the fact and set focus to the relevant agenda group. > 4. We are not able to update the fact using *"EntryPoint.update(Fact)"*. We could see that this occurs if the rule Engine starts firing facts and we subsequently update the fact in the session. > 5. According to drools, rule engine will handle the sequence of updates and firing of rules accordingly. > 6. But rule engine comes to halt state and there is no exception related to this. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2080) New Address which contains IP address and port

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2080?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2080: -------------------------------- There's a problem with {{AddressGenerator}} in {{JChannel}}: if more than one is installed, the returned address needs to be {{ExtendedUUID}}! This requires more investigation... > New Address which contains IP address and port > ---------------------------------------------- > > Key: JGRP-2080 > URL: https://issues.jboss.org/browse/JGRP-2080 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Currently, UUIDs are mapped to IpAddresses (InetAddress and port). The mappings are maintained in logical_address_cache in TP and populated via the discovery protocol. > If we encoded the IP address and port (6 bytes in IPv4, 18 bytes in IPv6) directly into the UUID, we would not have to maintain this cache anymore. At least not for IpAddresses, but still for UUID/logical_name mappings. > An {{IPv4UUID}} (credits to Neal Dillman) would look like this: > * 4 bytes: IPv4 address > * 2 bytes: port > * 12 bytes: random data (rest of the UUID) > When joining a cluster, the joiner would only need to discover the address of the coordinator and send a JOIN-REQ to it. The JOIN-RSP would contain the view, which contains all members, so the joiner has all addresses. Plus, the coord would also send a VIEW-CHANGE to all existing members, so they have the address of the new member, too. > When sending a unicast, the transport could simply extract the IpAddress from the first 6 bytes of the IPv4UUID to know the destination address. For multicasts, UDP is not an issue, and TCP would simply iterate over the current view and send the message to each member separately. > An IPv6UUID would need more than 16 bytes as it already needs 18 bytes for the address and the port. We might add another 6 bytes for uniqueness, to have a nice padding at 24 bytes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-605) Add an allowAllSaslMechanisms option

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-605: ------------------------------------ Summary: Add an allowAllSaslMechanisms option Key: ELY-605 URL: https://issues.jboss.org/browse/ELY-605 Project: WildFly Elytron Issue Type: Feature Request Components: Authentication Client Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta7 This way we can add all and just filter the mechanisms we want to exclude in the configuration. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1594) CLI to support attached file streams

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1594?page=com.atlassian.jira.plugi... ] Jean-Francois Denise updated WFCORE-1594: ----------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1698 > CLI to support attached file streams > ------------------------------------ > > Key: WFCORE-1594 > URL: https://issues.jboss.org/browse/WFCORE-1594 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > This entry tracks the addition of a support for attached files in CLI operations, > Operation arguments of type INT and annotated with *attached-stream* and *filesystem-path* must be attached to the Operation. > Users will not deal directly with streams, but with file paths. > The CLI must discover such arguments and: > 1) Propose completion by looking up the file system > 2) Replace the path by a stream index > 3) Send the File streams as attachements > This must be supported both in batch and non batch mode. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-923) Execution timeout for CLI operations

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-923?page=com.atlassian.jira.plugin... ] Jean-Francois Denise updated WFCORE-923: ---------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1697 > Execution timeout for CLI operations > ------------------------------------ > > Key: WFCORE-923 > URL: https://issues.jboss.org/browse/WFCORE-923 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Affects Versions: 2.0.0.Beta4 > Reporter: Lyle Wang > Assignee: Alexey Loubyansky > Labels: cli, timeout > > It will be great if we could have a timeout setting to "stop-the-CLI-execution-after-nnn-seconds" , for all general CLI operations. > Specifically, during some CLI operations, for example "deploy" or "reload", it is possible that things get stuck and hang-up, CLI cannot get back / return to the user after a long waiting. In this case, if we're able to setup an "execution timeout" and let CLI return with an error message, that would be much better. User should be able to know command execution results by viewing the related logs or checking the status. > Currently there is "--timeout" setting when running "jboss-cli.sh", but that seems only effective on "connect" operation, tried to use this timeout with a CLI script file, which has "deploy" inside (./jboss-cli.sh --file=test.cli --timeout=xxx), it doesn't work when the deployment takes a long time. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1673) Testsuite: tests for CLI controller aliases

by Martin Schvarcbacher (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1673?page=com.atlassian.jira.plugi... ] Martin Schvarcbacher updated WFCORE-1673: ----------------------------------------- Description: Added integration tests for server aliases defined in jboss-cli.xml Usage in bin/jboss-cli.xml: {code:xml} <controllers> <controller name="ServerOne"> <protocol>http-remoting</protocol> <host>localhost</host> <port>9990</port> </controller> </controllers> {code} {code:bash} ./bin/jboss-cli.sh --controller=ServerOne --connect {code} +*TEST PLAN*+ # set invalid default controller configuration to ensure all settings are being loaded only from controller aliases # connect to controller alias with all options (protocol, hostname, port) specified # protocol specified in <default-controller> overrides <default-protocol> when calling --connect without --controller was: Added integration tests for server aliases defined in jboss-cli.xml Usage in bin/jboss-cli.xml: {code:xml} <controllers> <controller name="ServerOne"> <protocol>http-remoting</protocol> <host>localhost</host> <port>9990</port> </controller> </controllers> {code} {code:bash} ./bin/jboss-cli.sh --controller=ServerOne --connect {code} +*TEST PLAN*+ # set invalid default controller configuration to ensure all settings are being loaded only from controller aliases # connect to controller alias with all options (protocol, hostname, port) specified # protocol specified in <default-controller> overrides <default-protocol> when calling --connect without --controller # <default-protocol use-legacy-override=true> && no protocol specified && port=9999 →use remoting:// # <default-protocol use-legacy-override=false> && no protocol specified && port=9999 → use protocol from <default-protocol> # no protocol specified in <default-controller> → use <default-protocol> > Testsuite: tests for CLI controller aliases > ------------------------------------------- > > Key: WFCORE-1673 > URL: https://issues.jboss.org/browse/WFCORE-1673 > Project: WildFly Core > Issue Type: Task > Components: CLI, Test Suite > Reporter: Martin Schvarcbacher > Assignee: Martin Schvarcbacher > Priority: Minor > > Added integration tests for server aliases defined in jboss-cli.xml > Usage in bin/jboss-cli.xml: > {code:xml} > <controllers> > <controller name="ServerOne"> > <protocol>http-remoting</protocol> > <host>localhost</host> > <port>9990</port> > </controller> > </controllers> > {code} > {code:bash} > ./bin/jboss-cli.sh --controller=ServerOne --connect > {code} > +*TEST PLAN*+ > # set invalid default controller configuration to ensure all settings are being loaded only from controller aliases > # connect to controller alias with all options (protocol, hostname, port) specified > # protocol specified in <default-controller> overrides <default-protocol> when calling --connect without --controller -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6883) A client is not able to invoke EJB's deployed as "HASingleton deployment"

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created WFLY-6883: -------------------------------------- Summary: A client is not able to invoke EJB's deployed as "HASingleton deployment" Key: WFLY-6883 URL: https://issues.jboss.org/browse/WFLY-6883 Project: WildFly Issue Type: Bug Components: Clustering, EJB Affects Versions: 10.0.0.Final, 11.0.0.Alpha1 Reporter: Wolf-Dieter Fink Assignee: Paul Ferraro Given that an application contains a SLSB and is clustered, any EJB client will be updated to have a view off all cluster members and is able to use and failover to any node in the cluster no matter whether it is in the initial list of servers. Now if the application is marked as "singleton-deployment" via jboss-all.xml and deployed to all servers only one server in a cluster will pick it and make it active. Now the expectation is that a client is routed to that server no matter whether this special server is included in the clients initial connection list. The interesting thing is that the client.log show that both servers are connected it the application is NOT marked as singleton But only the initial server is connected if the app is marked as singleton! -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2016