[JBoss JIRA] (WFLY-4809) Upgrade HAL to 2.7.4.Final
by Heiko Braun (JIRA)
Heiko Braun created WFLY-4809:
---------------------------------
Summary: Upgrade HAL to 2.7.4.Final
Key: WFLY-4809
URL: https://issues.jboss.org/browse/WFLY-4809
Project: WildFly
Issue Type: Component Upgrade
Components: Web Console
Reporter: Heiko Braun
Assignee: Harald Pehl
Fix For: 9.0.0.Final
Final fixes for the upcoming 9 release.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFLY-4793) undertow load balancing dont work
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4793?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-4793.
----------------------------------
Resolution: Rejected
According to your forum post you have started Wildfly with the following:
-bjboss.bind.address=192.168.40.56
It should be -D rather than -b:
-Djboss.bind.address=192.168.40.56
That is why you get a failure to connect in the browser when connecting to 192.168.40.56
> undertow load balancing dont work
> ---------------------------------
>
> Key: WFLY-4793
> URL: https://issues.jboss.org/browse/WFLY-4793
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 9.0.0.CR1, 9.0.0.CR2
> Environment: Ubuntu 15.04 (x64): Java 1.7.0_79 (x32 and x64) and Java 1.8.0_45 (x32 and x64)
> Windows 7 Ultimate (x64): Java 1.8.0_45 (x32)
> Reporter: Gabriel Gaudina
> Assignee: Stuart Douglas
> Labels: high_availability, load-balancing, undertow
>
> After configuring two server groups and 3 servers for load balancing (1 balancer, 2 backends) using undertow (without apache mod_cluster), load balancing fails getting "404 - Not Found" or "unable to connect"
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFLY-3872) Recurring failure of EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3872?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-3872:
------------------------------------
Assignee: Alessio Soldano (was: Stuart Douglas)
I am 99% sure this is a web services issue and not an Undertow one, especially given that it started after a WS upgrade. From the web point of view there is nothing different about this compared to any of the other tests that make servlet requests.
> Recurring failure of EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-3872
> URL: https://issues.jboss.org/browse/WFLY-3872
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 9.0.0.Alpha1
> Reporter: Brian Stansberry
> Assignee: Alessio Soldano
>
> Since https://github.com/wildfly/wildfly/pull/6660 was submitted, EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn is failing regularly. Not every time but very often.
> Alessio, you mentioned seeing some error logging from XAResourceRecoveryImpl, but that's in the logs on successful runs as well, and occurs prior to the test as well. That's a period background task from the transaction manager trying to perform recovery of some previous transaction. I don't see why it would have any impact on this test.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (DROOLS-823) Run "jdeps -jdkinternals" on all drools/optaplanner/jbpm jars and send report to developers
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-823?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet updated DROOLS-823:
------------------------------------
Description:
We need to prepare for Java 9.
See
https://twitter.com/royvanrijn/status/611479966824439808
With JDK 8 run that command on every jar and war that we produce in kie (such as drools-core, optaplanner.core, etc) with quick script (use tmp copy of mvn-all.sh or something).
Then send that report the to bsig list.
Make a jira for every project that has 1 or more errors in the list, so we can track this risk properly.
was:
We need to prepare for Java 9 modules.
See
https://twitter.com/royvanrijn/status/611479966824439808
With JDK 8 run that command on every jar and war that we produce in kie (such as drools-core, optaplanner.core, etc) with quick script (use tmp copy of mvn-all.sh or something).
Then send that report the to bsig list.
Make a jira for every project that has 1 or more errors in the list, so we can track this risk properly.
> Run "jdeps -jdkinternals" on all drools/optaplanner/jbpm jars and send report to developers
> -------------------------------------------------------------------------------------------
>
> Key: DROOLS-823
> URL: https://issues.jboss.org/browse/DROOLS-823
> Project: Drools
> Issue Type: Task
> Reporter: Geoffrey De Smet
> Assignee: Michael Biarnes Kiefer
> Priority: Minor
>
> We need to prepare for Java 9.
> See
> https://twitter.com/royvanrijn/status/611479966824439808
> With JDK 8 run that command on every jar and war that we produce in kie (such as drools-core, optaplanner.core, etc) with quick script (use tmp copy of mvn-all.sh or something).
> Then send that report the to bsig list.
> Make a jira for every project that has 1 or more errors in the list, so we can track this risk properly.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (DROOLS-823) Run "jdeps -jdkinternals" on all drools/optaplanner/jbpm jars and send report to developers
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-823?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet updated DROOLS-823:
------------------------------------
Description:
We need to prepare for Java 9 modules.
See
https://twitter.com/royvanrijn/status/611479966824439808
With JDK 8 run that command on every jar and war that we produce in kie (such as drools-core, optaplanner.core, etc) with quick script (use tmp copy of mvn-all.sh or something).
Then send that report the to bsig list.
Make a jira for every project that has 1 or more errors in the list, so we can track this risk properly.
was:
We need to prepare for Java 9 modules.
See
https://twitter.com/royvanrijn/status/611479966824439808
With JDK 8 run that command on every jar and war that we produce in kie (such as drools-core, optaplanner.core, etc) with quick script (use tmp copy of mvn-all.sh or something).
Then send that report the to bsig list.
Make a jira for every project that has an error in the list, so we can track this risk properly.
> Run "jdeps -jdkinternals" on all drools/optaplanner/jbpm jars and send report to developers
> -------------------------------------------------------------------------------------------
>
> Key: DROOLS-823
> URL: https://issues.jboss.org/browse/DROOLS-823
> Project: Drools
> Issue Type: Task
> Reporter: Geoffrey De Smet
> Assignee: Michael Biarnes Kiefer
> Priority: Minor
>
> We need to prepare for Java 9 modules.
> See
> https://twitter.com/royvanrijn/status/611479966824439808
> With JDK 8 run that command on every jar and war that we produce in kie (such as drools-core, optaplanner.core, etc) with quick script (use tmp copy of mvn-all.sh or something).
> Then send that report the to bsig list.
> Make a jira for every project that has 1 or more errors in the list, so we can track this risk properly.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFLY-4691) "Periodic Recovery" Exception in thread "bitronix-task-scheduler" java.lang.OutOfMemoryError
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-4691?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-4691:
-----------------------------------
Component/s: Transactions
> "Periodic Recovery" Exception in thread "bitronix-task-scheduler" java.lang.OutOfMemoryError
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-4691
> URL: https://issues.jboss.org/browse/WFLY-4691
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 9.0.0.CR1
> Reporter: Mike Mike
> Assignee: Jason Greene
>
> I am using a BitronixTransactionManager with xa-data-sources. After the migration from Jboss 7.1.1.FINAL to Wildfly 9.0.0.CR I noticed the following error in the server.log:
> 18:09:31,064 ERROR [stderr] (Periodic Recovery) Exception in thread "Periodic Recovery" Exception in thread "bitronix-task-scheduler" java.lang.OutOfMemoryError: GC overhead limit exceeded
> 18:09:31,064 ERROR [stderr] (Periodic Recovery) at java.util.Arrays.copyOf(Arrays.java:2271)
> 18:09:31,064 ERROR [stderr] (Periodic Recovery) at java.io.ByteArrayOutputStream.toByteArray(ByteArrayOutputStream.java:178)
> 18:09:31,064 ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.arjuna.state.OutputBuffer.buffer(OutputBuffer.java:162)
> 18:09:31,064 ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.arjuna.objectstore.FileSystemStore.allObjUidsInternal(FileSystemStore.java:265)
> 18:09:31,064 ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.arjuna.objectstore.FileSystemStore.allObjUids(FileSystemStore.java:160)
> 18:09:31,064 ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.arjuna.objectstore.ObjectStore.allObjUids(ObjectStore.java:69)
> 18:09:31,064 ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.jta.recovery.arjunacore.CommitMarkableResourceRecordRecoveryModule.periodicWorkSecondPass(CommitMarkableResourceRecordRecoveryModule.java:462)
> 18:09:31,064 ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:793)
> 18:09:31,064 ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:375)
> 18:09:31,064 ERROR [stderr] (bitronix-task-scheduler) java.lang.OutOfMemoryError: GC overhead limit exceeded
> After the error, the application was still working. I don't see an effect, yet. Does anybody has seen this error before?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 1 month