[JBoss JIRA] (WFCORE-411) Syntax error when applying patch and exiting jboss-cli
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-411?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-411:
-----------------------------------------
Ouch. That implies the whole approach of using the CLI as the patching tool is problematic. And allowing the server to be running is problematic as well, as the same problem can happen with standalone.sh, domain.sh, etc.
Using a separate package manager and not supporting the server continuing to run doesn't have that problem, although the question of how to update the package manager software itself still exists.
> Syntax error when applying patch and exiting jboss-cli
> ------------------------------------------------------
>
> Key: WFCORE-411
> URL: https://issues.jboss.org/browse/WFCORE-411
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Patching
> Reporter: Arun Gupta
> Assignee: Alexey Loubyansky
>
> [disconnected /] patch apply
> ../wildfly-8.1.0.Final-update/wildfly-8.1.0.Final.patch
> {
> "outcome" : "success",
> "result" : {}
> }
> [disconnected /]
> [disconnected /]
> [disconnected /]
> [disconnected /] exit
> logging.configuration already set in JAVA_OPTS
> ./bin/jboss-cli.sh: line 81: syntax error near unexpected token `fi'
> ./bin/jboss-cli.sh: line 81: `fi'
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (JGRP-1916) ConcurrentModificationException in FD_ALL
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1916?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1916.
----------------------------
Resolution: Done
Thanks Dan, fixed as suggested
> ConcurrentModificationException in FD_ALL
> -----------------------------------------
>
> Key: JGRP-1916
> URL: https://issues.jboss.org/browse/JGRP-1916
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.2
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Fix For: 3.6.3
>
>
> When DEBUG logging is enabled, FD_ALL logs the set of suspected members without proper synchronization. If another thread modifies the {{suspected_mbrs}} set at the same time, it can cause a {{ConcurrentModificationException}} and the {{SUSPECT}} event will be lost.
> {noformat}
> java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextEntry(HashMap.java:922)
> at java.util.HashMap$KeyIterator.next(HashMap.java:956)
> at java.util.AbstractCollection.toString(AbstractCollection.java:457)
> at java.lang.String.valueOf(String.java:2847)
> at java.lang.StringBuilder.append(StringBuilder.java:128)
> at org.jgroups.protocols.FD_ALL.suspect(FD_ALL.java:368)
> at org.jgroups.protocols.FD_ALL$TimeoutChecker.run(FD_ALL.java:444)
> at org.jgroups.util.TimeScheduler3$Task.run(TimeScheduler3.java:287)
> at org.jgroups.util.TimeScheduler3$RecurringTask.run(TimeScheduler3.java:321)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> I would also suggest adding a synchronized block in {{getSuspectedMembers()}}, {{init()}} and {{stop()}}.
> FD_ALL2 seems to have the same problem.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (WFLY-4387) Unable to configure ajaxTimeout in wildfly 8.2_Final
by Manjunatha KB (JIRA)
[ https://issues.jboss.org/browse/WFLY-4387?page=com.atlassian.jira.plugin.... ]
Manjunatha KB commented on WFLY-4387:
-------------------------------------
Thanks for response stuart.
One last query.. Is there any way to increase http connection timeout atlease...
> Unable to configure ajaxTimeout in wildfly 8.2_Final
> ----------------------------------------------------
>
> Key: WFLY-4387
> URL: https://issues.jboss.org/browse/WFLY-4387
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.2.0.Final
> Environment: OS : Windows 8.1
> WildFly: 8.2_Final
> Reporter: Manjunatha KB
> Assignee: Jason Greene
> Labels: wildfly
>
> Hi. Am newbie to wildfly. Am facing an issue in getting ajax response as my DB is taking some quite time due to huge data. I guess wildfly is throwing internal server error after exactly 10 seconds of request time. So i need to know is there is any attribute which I need to set in standalone.xml to increase this timeout. Exactly as there is "ajaxTimeOut" in apache Tomcat.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (WFCORE-411) Syntax error when applying patch and exiting jboss-cli
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-411?page=com.atlassian.jira.plugin... ]
Alexey Loubyansky commented on WFCORE-411:
------------------------------------------
The problem is that the patch updates, i.e. replaces jboss-cli.sh with a new version. So, after the cli process quits, the script continues its execution from the next line after the one launching the cli process. In the newly installed version of jboss-cli.sh at that line it is trying to add logging.configuration again.
> Syntax error when applying patch and exiting jboss-cli
> ------------------------------------------------------
>
> Key: WFCORE-411
> URL: https://issues.jboss.org/browse/WFCORE-411
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Patching
> Reporter: Arun Gupta
> Assignee: Alexey Loubyansky
>
> [disconnected /] patch apply
> ../wildfly-8.1.0.Final-update/wildfly-8.1.0.Final.patch
> {
> "outcome" : "success",
> "result" : {}
> }
> [disconnected /]
> [disconnected /]
> [disconnected /]
> [disconnected /] exit
> logging.configuration already set in JAVA_OPTS
> ./bin/jboss-cli.sh: line 81: syntax error near unexpected token `fi'
> ./bin/jboss-cli.sh: line 81: `fi'
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (JGRP-1916) ConcurrentModificationException in FD_ALL
by Dan Berindei (JIRA)
Dan Berindei created JGRP-1916:
----------------------------------
Summary: ConcurrentModificationException in FD_ALL
Key: JGRP-1916
URL: https://issues.jboss.org/browse/JGRP-1916
Project: JGroups
Issue Type: Bug
Affects Versions: 3.6.2
Reporter: Dan Berindei
Assignee: Bela Ban
Fix For: 3.6.3
When DEBUG logging is enabled, FD_ALL logs the set of suspected members without proper synchronization. If another thread modifies the {{suspected_mbrs}} set at the same time, it can cause a {{ConcurrentModificationException}} and the {{SUSPECT}} event will be lost.
{noformat}
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:922)
at java.util.HashMap$KeyIterator.next(HashMap.java:956)
at java.util.AbstractCollection.toString(AbstractCollection.java:457)
at java.lang.String.valueOf(String.java:2847)
at java.lang.StringBuilder.append(StringBuilder.java:128)
at org.jgroups.protocols.FD_ALL.suspect(FD_ALL.java:368)
at org.jgroups.protocols.FD_ALL$TimeoutChecker.run(FD_ALL.java:444)
at org.jgroups.util.TimeScheduler3$Task.run(TimeScheduler3.java:287)
at org.jgroups.util.TimeScheduler3$RecurringTask.run(TimeScheduler3.java:321)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{noformat}
I would also suggest adding a synchronized block in {{getSuspectedMembers()}}, {{init()}} and {{stop()}}.
FD_ALL2 seems to have the same problem.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (JBWEB-258) DigestAuthenticator generates duplicate nonces
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBWEB-258?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBWEB-258:
-----------------------------------------------
Radim Hatlapatka <rhatlapa(a)redhat.com> changed the Status of [bug 1188744|https://bugzilla.redhat.com/show_bug.cgi?id=1188744] from ON_QA to VERIFIED
> DigestAuthenticator generates duplicate nonces
> ----------------------------------------------
>
> Key: JBWEB-258
> URL: https://issues.jboss.org/browse/JBWEB-258
> Project: JBoss Web
> Issue Type: Bug
> Affects Versions: JBossWeb-2.1.12.GA, JBossWeb-7.0.16.GA, JBossWeb-7.2.0.Alpha3
> Reporter: Aaron Ogburn
> Assignee: Remy Maucherat
> Attachments: 21x.diff, 70x.diff, 72x.diff
>
>
> DigestAuthenticator currently generates nonces as a hash of the client's remote ip, the current time at generation time, and an internal server key. With high concurrent load in a scenario where many clients show a single ip (such as behind a loadbalancer/proxy), then it is very easy for DigestAuthenticator to give out duplicate nonces when they are generated at the same time.
> This then leads to authentication failues as counts for the duplicate nonces get out of whack.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (WFCORE-520) Random NPE in org.jboss.as.controller.OperationContextImpl.createTargetAttribute
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-520?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-520:
------------------------------------------------
Jan Martiska <jmartisk(a)redhat.com> changed the Status of [bug 1192181|https://bugzilla.redhat.com/show_bug.cgi?id=1192181] from ON_QA to VERIFIED
> Random NPE in org.jboss.as.controller.OperationContextImpl.createTargetAttribute
> --------------------------------------------------------------------------------
>
> Key: WFCORE-520
> URL: https://issues.jboss.org/browse/WFCORE-520
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha9
> Reporter: Brad Maxwell
> Assignee: Brian Stansberry
> Fix For: 1.0.0.Alpha19
>
> Attachments: JMXTest.java, server.log
>
>
> A NullPointerException randomly occurs in org.jboss.as.controller.OperationContextImpl.createTargetAttribute(OperationContextImpl.java:1172) when getMBeanCount is called over and over.
> See attached server.log and reproducer
> {noformat}
> 00:16:01,315 ERROR [org.jboss.as.controller.management-operation] (pool-2-thread-2) WFLYCTL0013: Operation ("check-default-resource-access") failed - address: ([
> ("core-service" => "management"),
> ("service" => "management-operations"),
> ("active-operation" => "-1652526387")
> ]): java.lang.NullPointerException
> at org.jboss.as.controller.OperationContextImpl.createTargetAttribute(OperationContextImpl.java:1172) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.OperationContextImpl.authorizeResource(OperationContextImpl.java:1136) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.OperationContextImpl.authorizeResource(OperationContextImpl.java:130) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.operations.global.ReadResourceDescriptionHandler$CheckResourceAccessHandler.execute(ReadResourceDescriptionHandler.java:467) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:700) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:535) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:303) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1158) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:328) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:197) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.ResourceAccessControlUtil.getResourceAccess(ResourceAccessControlUtil.java:85) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:51) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.RootResourceIterator.iterate(RootResourceIterator.java:43) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.ModelControllerMBeanHelper.getMBeanCount(ModelControllerMBeanHelper.java:105) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.getMBeanCount(ModelControllerMBeanServerPlugin.java:154) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.PluggableMBeanServerImpl.getMBeanCount(PluggableMBeanServerImpl.java:561) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.BlockingNotificationMBeanServer.getMBeanCount(BlockingNotificationMBeanServer.java:143) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.remotingjmx.protocol.v2.ServerProxy$GetMBeanCountHandler.handle(ServerProxy.java:655)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_51]
> at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_51]
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (JGRP-1915) JDBC_PING discovery fails when stale entries are found in the database
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1915?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1915:
--------------------------------
OK, I possibly have to re-activate an old algorithm:
* On a view V
** Every coordinator removes all members not in V from the DB table
** Every member inserts its information into the DB table (after a delay, to reduce chances of the deletion coming after the insertion)
* Periodically, every member M inserts its information into the DB table
This causes more DB traffic though...
> JDBC_PING discovery fails when stale entries are found in the database
> ----------------------------------------------------------------------
>
> Key: JGRP-1915
> URL: https://issues.jboss.org/browse/JGRP-1915
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.1
> Reporter: Patrick Haas
> Assignee: Bela Ban
> Fix For: 3.6.3
>
>
> Node: "CHQ-PATRICKH-55008"
> Database contains two rows.. other node is dead but was unable to remove the JDBC entry.
> 1) JChannel.connect(...)
> 2) JChannel.down(Event[CONNECT_WITH_STATE_TRANSFER_USE_FLUSH])
> 3) STATE_TRANSFER -> FRAG2 -> MFC -> UFC -> GMS
> 4) GMS.down(...) calls out to joinWithStateTransfer -> joinInternal(...)
> JDBC pulls the node list from the database table.
> Ping Data:
> - CHQ-PATRICKH-3895, name=CHQ-PATRICKH-3895, addr=10.1.130.228:55503, server
> - CHQ-PATRICKH-55008, name=CHQ-PATRICKH-55008, addr=10.1.130.228:57489
> joinInternal is a never-terminating while loop:
> - down: Event.FIND_INITIAL_MBRS_EVT
> - inspect responses -- no valid join responses
> - responses are NOT empty -> does not become singletonMember
> - gets all coordinators (none)
> - Sorts all nodes by GUID in a TreeSet
> - Is first of all joiners?
> - No, another joiner is listed first
> ... repeat forever
> When the process is restarted and a node ID < than the existing db entry is generated, it successfully takes over as owner.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months