[JBoss JIRA] (JGRP-1897) ENCRYPT might drop messages during key change
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1897?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1897.
----------------------------
Resolution: Won't Fix
As discussed
> ENCRYPT might drop messages during key change
> ---------------------------------------------
>
> Key: JGRP-1897
> URL: https://issues.jboss.org/browse/JGRP-1897
> Project: JGroups
> Issue Type: Bug
> Reporter: Tero Leppikangas
> Assignee: Bela Ban
> Fix For: 3.6.2
>
>
> ENCRYPT might drop some (unicast) messages encrypted with unknown key if the delivery of new view is delayed.
> This problem was noticed while doing some stress testing on the fix for JGRP-1893.
> When view changes, coordinator multicasts the new view after which is starts using new symmetric keys. If some node receives a message sent with the new key before the new view is received, the received message will be dropped since it cannot be decrypted.
> We thought of possible solutions to be.
> 1. Sender specific queue holding the messages received.
> 2. Starting to queue up messages until new view has been received
> I have implemented the second option which is quite straightforward, but it could lead into problems when receiving message with unknown key that is not related to coming view change.
> I wonder if there is another way to overcome this problem?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (JGRP-1908) Optional Executing protocol behavior to not attempt to repeat tasks
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1908?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1908:
--------------------------------
As I mentioned on the forum, I don't think there's a way to guarantee these semantics in the current implementation. For instance, if you have a partition, then a task could be executed more than once.
There's only two alternatives to ensure these semantics:
# Use a shared DB to store the status of a task and (perhaps) intermediate results. Nodes which cannot access the DB don't attempt to execute the task. This is a single point of failure though
# Use a consensus-based system (e.g. jgroups-raft) to execute the task; on a network partition only the partition with the majority would be able to execute the task. This, however, hampers availability if no majority can be garnered.
> Optional Executing protocol behavior to not attempt to repeat tasks
> -------------------------------------------------------------------
>
> Key: JGRP-1908
> URL: https://issues.jboss.org/browse/JGRP-1908
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Anuj Shah
> Assignee: William Burns
> Labels: executionservice
> Fix For: 3.6.2
>
>
> As discussed on forum:
> http://jgroups.1086181.n5.nabble.com/jgroups-users-ExecutionService-at-le...
> {quote}
> I've noticed that runnable tasks submitted to the ExecutionService can be run more than once!
> This would happen when a member executing the task is suspected and is removed from the cluster. The protocol handles this by resubmitting the request in Executing#handleView. I note the following JavaDoc
> // The person currently servicing our request has gone down
> // without completing so we have to keep our request alive by
> // sending ours back to the coordinator
> The problem is that there is no guarantee that the request was not completed.
> For my application a member executing the task had a absurdly long GC pause (30s) which meant it was temporarily removed from the cluster, when the pause completed it happily continued executing the task which had already been resubmitted and completed. The task in question involves modifying the database and is quite destructive, so you can imagine the fallout.
> I was hoping to get an opinion of if we think this behaviour is correct, especially since we are implementing a standard java,util.concurrent interface. (I couldn't find anything in the ExecutorService JavaDoc to say it is wrong though)
> Perhaps there could be control over the behaviour:
> * At least once - assumes task failed and resubmits
> * At most once - assumes task completed and cleans up - may not actually be complete
> * Exactly once - not sure if this is possible
> {quote}
> There is a simple change to exhibit the at least once behaviour by ignoring consumers that have left. I have the patch in my fork:
> https://github.com/anujshahwork/JGroups/commit/0f2c1f6f9ed57744841acdd192...
> Which my project is using. This can be wrapped in some simple configuration on the protocol to control the behaviour and would be a useful addition.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (JGRP-1911) Use consensus for some subsystems
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1911?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1911:
---------------------------
Fix Version/s: 4.0
(was: 3.6.2)
> Use consensus for some subsystems
> ---------------------------------
>
> Key: JGRP-1911
> URL: https://issues.jboss.org/browse/JGRP-1911
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Provide options for several subsystems to run with consensus, e.g.
> * {{SEQUENCER}}
> * {{CENTRAL_LOCK}}
> * {{COUNTER}}
> * {{TOA}}
> * Clustered singletons etc
> For example, with the current impl of distributed counters ({{COUNTER}}), the same counter can be available multiple times if we have a split brain. It is currently up to the user to merge counters with different values after a split brain heals.
> This is OK, but we should provide a second implementation, based on jgroups-raft, which uses consensus to determine the counter maintainer in a split brain scenario. This will forfeit availability in favor of consistency.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4280) Component upgrade of Hibernate Validator to version 5.1.next.Final when HV-861 is fixed
by Hardy Ferentschik (JIRA)
[ https://issues.jboss.org/browse/WFLY-4280?page=com.atlassian.jira.plugin.... ]
Hardy Ferentschik commented on WFLY-4280:
-----------------------------------------
thanks [~juan.hernandez]. I have not tried your binary yet, but I was able to re-produce the exception by using your original test setup running Wildfly with an OpenJDK version:
{noformat}
openjdk version "1.7.0-b147"
OpenJDK Runtime Environment (build 1.7.0-b147-20111031)
OpenJDK 64-Bit Server VM (build 21.0-b17, mixed mode)
{noformat}
Somehow a very elusive bug. Now that I am able to re-produce it, I am hoping to be able to track it down.
> Component upgrade of Hibernate Validator to version 5.1.next.Final when HV-861 is fixed
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-4280
> URL: https://issues.jboss.org/browse/WFLY-4280
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.1.0.Final, 8.2.0.Final
> Environment: Fedora 21, OpenJDK 1.8.0_25-b18.
> Reporter: Juan Hernández
> Assignee: Scott Marlow
> Attachments: hv-861-1.0-SNAPSHOT.jar, hv-861.tar.gz
>
>
> The version of Hibernate Validator included in WildFly 8.1 and 8.2 throws an {{ArrayIndexOutOfBounds}} exception when deploying some applications. This is already reported in the Hibernate Validator JIRA:
> https://hibernate.atlassian.net/browse/HV-861
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (REMJMX-84) Jboss JMX: Operation failed with status WAITING
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/REMJMX-84?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on REMJMX-84:
----------------------------------------
Yes in theory the newer client should work against the older server and the fix needed here is in the client.
> Jboss JMX: Operation failed with status WAITING
> ------------------------------------------------
>
> Key: REMJMX-84
> URL: https://issues.jboss.org/browse/REMJMX-84
> Project: Remoting JMX
> Issue Type: Bug
> Environment: jboss-as-7.1.1.Final on windows server
> Reporter: Abhishek Apoorva
> Assignee: Darran Lofthouse
> Fix For: 2.0.1.CR1
>
>
> Version : jboss-as-7.1.1.Final on windows server
> I am getting below mentioned strange issue intermittently while fetching
> Jboss JMX Mbean.
> Can anyone help me to find the real cause of the issue? Secong thing is why it is coming intermittently either it should come always or it should not come at all.
> JMXConnectorFactory.connect(serviceURL, environment);
> While executing above mentioned line system is throwing below mentioned exception.
> {noformat}
> May 08 02:30:53:375 [DC#0, jboss] java.lang.RuntimeException: Operation failed with status WAITING
> at org.jboss.remotingjmx.RemotingConnector.internalRemotingConnect(RemotingConnector.java:216)
> at org.jboss.remotingjmx.RemotingConnector.internalConnect(RemotingConnector.java:143)
> at org.jboss.remotingjmx.RemotingConnector.connect(RemotingConnector.java:94)
> at javax.management.remote.JMXConnectorFactory.connect(Unknown Source)
> at com.nimsoft.nimbus.probe.application.jboss.JmxConnection.createConnection(JmxConnection.java:68)
> at com.nimsoft.nimbus.probe.application.jsr160.Entity.createConnection(Entity.java:1772)
> at com.nimsoft.nimbus.probe.application.jsr160.Entity.getValue(Entity.java:1567)
> at com.nimsoft.nimbus.probe.application.extractbase.Extract.processMonitor(Extract.java:1324)
> at com.nimsoft.nimbus.probe.application.extractbase.Extract.processResource(Extract.java:1908)
> at com.nimsoft.nimbus.probe.application.extractbase.Extract$DataCollector.run(Extract.java:1158)
> at java.lang.Thread.run(Unknown Source)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4278) byte[] saved to Oracle BLOB can not be read back
by Lubos Pechac (JIRA)
[ https://issues.jboss.org/browse/WFLY-4278?page=com.atlassian.jira.plugin.... ]
Lubos Pechac commented on WFLY-4278:
------------------------------------
I think it's this: https://hibernate.atlassian.net/browse/HHH-9263
> byte[] saved to Oracle BLOB can not be read back
> ------------------------------------------------
>
> Key: WFLY-4278
> URL: https://issues.jboss.org/browse/WFLY-4278
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 8.2.0.Final
> Environment: Linux 64bit, Oracle JDK 7 or 8, WildFly 8.2.0.Final
> Reporter: Lubos Pechac
> Assignee: Scott Marlow
> Attachments: wildfly-testcase.zip
>
>
> Since upgrading to Wildfly (Hibernate 4.3.7) we are experiencing problems persisting certain entities to an Oracle database.
> The entity contains an attribute of type java.lang.Serializable and is mapped to an Oracle BLOB column.
> When the value of the Serializable attribute is a byte[] then this is not properly serialized to the database.
> The value stored does not correspond to the Java Object Serialization Specification, instead the exact contents of the byte array are saved, without the usual header information associated with Java Object Serialization.
>
> When we try to read this back from the database into our entity we get the exception shown below, so basically Hibernate cannot read what it wrote.
>
> We have attached a test case to demonstrate this problem.
>
> Caused by: org.hibernate.type.SerializationException: could not deserialize
> at org.hibernate.internal.util.SerializationHelper.doDeserialize(SerializationHelper.java:262) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.internal.util.SerializationHelper.deserialize(SerializationHelper.java:306) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.type.descriptor.java.SerializableTypeDescriptor.fromBytes(SerializableTypeDescriptor.java:155) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.type.descriptor.java.SerializableTypeDescriptor.wrap(SerializableTypeDescriptor.java:130) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.type.descriptor.java.SerializableTypeDescriptor.wrap(SerializableTypeDescriptor.java:44) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.type.descriptor.sql.VarbinaryTypeDescriptor$2.doExtract(VarbinaryTypeDescriptor.java:71) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.type.descriptor.sql.BasicExtractor.extract(BasicExtractor.java:64) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.type.AbstractStandardBasicType.nullSafeGet(AbstractStandardBasicType.java:267) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.type.AbstractStandardBasicType.nullSafeGet(AbstractStandardBasicType.java:263) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.type.AbstractStandardBasicType.nullSafeGet(AbstractStandardBasicType.java:253) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.type.AbstractStandardBasicType.hydrate(AbstractStandardBasicType.java:338) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.persister.entity.AbstractEntityPersister.hydrate(AbstractEntityPersister.java:2969) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.loader.plan.exec.process.internal.EntityReferenceInitializerImpl.loadFromResultSet(EntityReferenceInitializerImpl.java:324) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.loader.plan.exec.process.internal.EntityReferenceInitializerImpl.hydrateEntityState(EntityReferenceInitializerImpl.java:251) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.readRow(AbstractRowReader.java:107) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.loader.plan.exec.internal.EntityLoadQueryDetails$EntityLoaderRowReader.readRow(EntityLoadQueryDetails.java:255) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.loader.plan.exec.process.internal.ResultSetProcessorImpl.extractResults(ResultSetProcessorImpl.java:129) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:138) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:102) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(AbstractLoadPlanBasedEntityLoader.java:186) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.loader.entity.plan.LegacyBatchingEntityLoaderBuilder$LegacyBatchingEntityLoader.load(LegacyBatchingEntityLoaderBuilder.java:130) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:4126) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:503) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:468) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:213) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:275) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:151) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1070) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.internal.SessionImpl.access$2000(SessionImpl.java:176) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2551) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.internal.SessionImpl.get(SessionImpl.java:955) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1110) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final]
> ... 183 more
> Caused by: java.io.StreamCorruptedException: invalid stream header: 63726561
> at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:804) [rt.jar:1.7.0_71]
> at java.io.ObjectInputStream.<init>(ObjectInputStream.java:299) [rt.jar:1.7.0_71]
> at org.hibernate.internal.util.SerializationHelper$CustomObjectInputStream.<init>(SerializationHelper.java:328) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.internal.util.SerializationHelper$CustomObjectInputStream.<init>(SerializationHelper.java:318) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> at org.hibernate.internal.util.SerializationHelper.doDeserialize(SerializationHelper.java:237) [hibernate-core-4.3.7.Final.jar:4.3.7.Final]
> ... 214 more
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-2391) Wildfly caches content in exploded mode, breaking developer productivity
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2391?page=com.atlassian.jira.plugin.... ]
Stuart Douglas updated WFLY-2391:
---------------------------------
You can remove the buffer cache from the undertow subsystem.
It really should not be an issue though. For exploded deployments the TTL
is 2 second, and in most cases the watch service will invalidate it
immediately.
Stuart
On Mon, 16 Feb 2015 7:16 pm Max Rydahl Andersen (JIRA) <issues(a)jboss.org>
> Wildfly caches content in exploded mode, breaking developer productivity
> ------------------------------------------------------------------------
>
> Key: WFLY-2391
> URL: https://issues.jboss.org/browse/WFLY-2391
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Beta1
> Environment: MacOSX with JBossTools 4.1.1.Beta1
> Reporter: Xavier Coulon
> Assignee: Stuart Douglas
> Priority: Critical
> Fix For: 8.0.0.CR1
>
> Attachments: jboss-as-kitchensink-html5-mobile.war.zip
>
>
> While I was building a sample application with JBoss Tools 4.1.1.beta1 on WildFly 8.0.Beta1, I noticed that after a few minutes (or a few browser requests), the content of my index.html file seemed to be cached by the server, although I used the "exploded content" deployment mode (since I published the content using the WildFly Server Adapter in JBoss Tools).
>
> I checked the actual content of the index.html in the deployments folder and it contained the latest changes, which means that the JBoss Tools Server Adapter is doing its job well ;-)
> I also tried to edit the index.html file directly in the deployments folder, and once again, I got no update in both Chrome and Firefox browsers.
>
> I checked in the "Network" tab of the browsers and could see that the server response for the index.html page had a "200 OK" status, which means that there's no browser caching involved.
> I tried to get the index.html page with cUrl and got the same old version, which definitely excludes a browser caching issue.
> At the end of the dat, this means that after a few changes, my browsers keep getting an old version of the deployed resources, which in turns means that I have to stop and restart the server to get the new content, and this is pretty bad in term of dev productivity.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFCORE-544) Inconsistent handling of system properties.
by Emmanuel Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-544?page=com.atlassian.jira.plugin... ]
Emmanuel Hugonnet reassigned WFCORE-544:
----------------------------------------
Assignee: Emmanuel Hugonnet
> Inconsistent handling of system properties.
> --------------------------------------------
>
> Key: WFCORE-544
> URL: https://issues.jboss.org/browse/WFCORE-544
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Emmanuel Hugonnet
> Assignee: Emmanuel Hugonnet
>
> Description of problem:
> Having a domain with a single server group and two eap hosts (all on localhost), following system property cause server to fail on startup:
> <property name="org.jbpm.designer.perspective" value="${org.jbpm.designer.perspective:full}"/>
> The problem occurs only in definition with possibility to override default value - <property name="X" value="${Y:default}"/>, where X = Y
> Please see the error message in attached server log excerpt.
> More interesting is the fact that the issue shows with domain mode only, standalone mode works with properties defined as above.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months