[JBoss JIRA] (JGRP-2263) JGRP000225: failed unmarshalling buffer into return value
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2263?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2263.
----------------------------
Resolution: Done
> JGRP000225: failed unmarshalling buffer into return value
> ---------------------------------------------------------
>
> Key: JGRP-2263
> URL: https://issues.jboss.org/browse/JGRP-2263
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.11
> Environment: jdk1.8.0_66.jdk
> osx 10.10 & ubuntu 17.10
> Reporter: rama rama
> Assignee: Bela Ban
> Fix For: 4.0.12
>
> Attachments: SimpleChat.java
>
>
> trying to send a class that previous work with 3.x return
> "failed unmarshalling buffer into return value"
> jgroups instance it's configured with the default settings
> i create a test case to reproduce it, executing this class on my 2 boxes return
> ----
> GRAVE: JGRP000225: failed unmarshalling buffer into return value
> java.lang.InstantiationException: com.eg.util.comm.SimpleChat$EError
> at java.lang.Class.newInstance(Class.java:427)
> at org.jgroups.util.Util.readException(Util.java:899)
> at org.jgroups.util.Util.exceptionFromStream(Util.java:843)
> at org.jgroups.util.Util.exceptionFromStream(Util.java:831)
> at org.jgroups.util.Util.objectFromStream(Util.java:782)
> at org.jgroups.util.Util.objectFromStream(Util.java:742)
> at org.jgroups.blocks.RequestCorrelator.replyFromBuffer(RequestCorrelator.java:463)
> at org.jgroups.blocks.RequestCorrelator.handleResponse(RequestCorrelator.java:408)
> at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:363)
> at org.jgroups.blocks.RequestCorrelator.receiveMessageBatch(RequestCorrelator.java:326)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:589)
> at org.jgroups.JChannel.up(JChannel.java:837)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:896)
> at org.jgroups.stack.Protocol.up(Protocol.java:372)
> at org.jgroups.protocols.RSVP.up(RSVP.java:233)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:196)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:416)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:416)
> at org.jgroups.stack.Protocol.up(Protocol.java:372)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:293)
> at org.jgroups.protocols.UNICAST3.deliverBatch(UNICAST3.java:1024)
> at org.jgroups.protocols.UNICAST3.removeAndDeliver(UNICAST3.java:833)
> at org.jgroups.protocols.UNICAST3.handleBatchFromSelf(UNICAST3.java:520)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:435)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:697)
> at org.jgroups.protocols.BARRIER.up(BARRIER.java:195)
> at org.jgroups.stack.Protocol.up(Protocol.java:372)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:212)
> at org.jgroups.stack.Protocol.up(Protocol.java:372)
> at org.jgroups.stack.Protocol.up(Protocol.java:372)
> at org.jgroups.stack.Protocol.up(Protocol.java:372)
> at org.jgroups.protocols.TP.passBatchUp(TP.java:1274)
> at org.jgroups.util.MaxOneThreadPerSender$BatchHandlerLoop.passBatchUp(MaxOneThreadPerSender.java:284)
> at org.jgroups.util.SubmitToThreadPool$BatchHandler.run(SubmitToThreadPool.java:136)
> at org.jgroups.util.MaxOneThreadPerSender$BatchHandlerLoop.run(MaxOneThreadPerSender.java:273)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NoSuchMethodException: com.eg.util.comm.SimpleChat$EError.<init>()
> at java.lang.Class.getConstructor0(Class.java:3082)
> at java.lang.Class.newInstance(Class.java:412)
> ... 37 more
> -----
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (WFLY-10290) jboss.iiop-openjdk.poa-service.namingpoa service reload issues after server migration
by Petr Kremensky (JIRA)
Petr Kremensky created WFLY-10290:
-------------------------------------
Summary: jboss.iiop-openjdk.poa-service.namingpoa service reload issues after server migration
Key: WFLY-10290
URL: https://issues.jboss.org/browse/WFLY-10290
Project: WildFly
Issue Type: Bug
Components: IIOP, Migration
Reporter: Petr Kremensky
Assignee: Tomasz Adamski
Priority: Critical
*jboss.iiop-openjdk.poa-service.namingpoa* service throws java.net.BindException: Address already in use upon server reload after manual migration from older EAP release.
The issue can be reproduced with EAP 7.1.0 as TARGET_HOME as well.
*steps to reproduce* with the current (720397b26d) wildfly master:
{noformat}
WORKSPACE=`pwd`
CONFIG=standalone-full-ha.xml
unzip -q jboss-eap-6.4.19.zip
cp -r wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT wildfly
SOURCE_HOME=${WORKSPACE}/jboss-eap-6.4
TARGET_HOME=${WORKSPACE}/wildfly
cp ${SOURCE_HOME}/standalone/configuration/${CONFIG} ${TARGET_HOME}/standalone/configuration
${TARGET_HOME}/bin/standalone.sh -c ${CONFIG} --start-mode=admin-only &
${TARGET_HOME}/bin/jboss-cli.sh --connect --controller=remote://localhost:9999
# Migrate
/subsystem=jacorb:migrate
/subsystem=messaging:migrate
/subsystem=web:migrate
/subsystem=cmp:remove
/extension=org.jboss.as.cmp:remove
/subsystem=jaxr:remove
/extension=org.jboss.as.jaxr:remove
/subsystem=threads:remove
/extension=org.jboss.as.threads:remove
# Enable console logging
/subsystem=logging/pattern-formatter=COLOR-PATTERN:add(pattern="%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n")
/subsystem=logging/console-handler=CONSOLE:add(level=INFO, named-formatter=COLOR-PATTERN)
/subsystem=logging/root-logger=ROOT:add-handler(name=CONSOLE)
# reload the server twice to get the exception
reload
reload
{noformat}
*server log errors*
{noformat}
12:01:52,041 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "iiop-openjdk")]) - failure description: {
"WFLYCTL0080: Failed services" => {"jboss.iiop-openjdk.poa-service.rootpoa" => "WFLYIIOP0098: Failed to resolve initial reference RootPOA
Caused by: org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 216 completed: No
Caused by: java.net.BindException: Address already in use"},
"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
"Services that were unable to start:" => [
"jboss.iiop-openjdk.poa-service.irpoa",
"jboss.iiop-openjdk.poa-service.namingpoa"
],
"Services that may be the cause:" => ["jboss.iiop-openjdk.poa-service.namingpoa"]
}
}
{noformat}
*Exception stack trace*
{noformat}
12:01:51,881 SEVERE [javax.enterprise.resource.corba._DEFAULT_.rpc.transport] (MSC service thread 1-6) "IOP00410216: (COMM_FAILURE) Unable to create listener thread on the specified port: 3529": org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 216 completed: No
at com.sun.corba.se.impl.logging.ORBUtilSystemException.createListenerFailed(ORBUtilSystemException.java:2632)
at com.sun.corba.se.impl.logging.ORBUtilSystemException.createListenerFailed(ORBUtilSystemException.java:2651)
at com.sun.corba.se.impl.transport.SocketOrChannelAcceptorImpl.initialize(SocketOrChannelAcceptorImpl.java:164)
at com.sun.corba.se.impl.transport.CorbaTransportManagerImpl.getAcceptors(CorbaTransportManagerImpl.java:218)
at com.sun.corba.se.impl.transport.CorbaTransportManagerImpl.addToIORTemplate(CorbaTransportManagerImpl.java:236)
at com.sun.corba.se.spi.oa.ObjectAdapterBase.initializeTemplate(ObjectAdapterBase.java:122)
at com.sun.corba.se.impl.oa.poa.POAImpl.initialize(POAImpl.java:404)
at com.sun.corba.se.impl.oa.poa.POAImpl.makeRootPOA(POAImpl.java:272)
at com.sun.corba.se.impl.oa.poa.POAFactory$1.evaluate(POAFactory.java:205)
at com.sun.corba.se.impl.orbutil.closure.Future.evaluate(Future.java:46)
at com.sun.corba.se.impl.resolver.LocalResolverImpl.resolve(LocalResolverImpl.java:40)
at com.sun.corba.se.impl.resolver.CompositeResolverImpl.resolve(CompositeResolverImpl.java:45)
at com.sun.corba.se.impl.orb.ORBImpl.resolve_initial_references(ORBImpl.java:1169)
at org.wildfly.iiop.openjdk.service.CorbaPOAService.start(CorbaPOAService.java:156)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1714)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1693)
at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1540)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1364)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.net.BindException: Address already in use
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:433)
at sun.nio.ch.Net.bind(Net.java:425)
at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
at org.wildfly.iiop.openjdk.security.SocketFactoryBase.createServerSocket(SocketFactoryBase.java:59)
at org.wildfly.iiop.openjdk.security.NoSSLSocketFactory.createServerSocket(NoSSLSocketFactory.java:50)
at com.sun.corba.se.impl.transport.SocketOrChannelAcceptorImpl.initialize(SocketOrChannelAcceptorImpl.java:161)
... 19 more
{noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (JGRP-2263) JGRP000225: failed unmarshalling buffer into return value
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2263?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2263 at 4/24/18 5:53 AM:
---------------------------------------------------------
OK, so the problem is that exceptions were marshalled/unmarshalled as a special case, and the marshalling included only the stack trace and error message.
This was done to improve performance of RPCs. However, as exceptions are not thrown frequently, I'll remove the TYPE_EXCEPTION type again and marshall exceptions as Serializable.
This way, custom exceptions with state ({{code}}) will be marshalled correctly, too.
was (Author: belaban):
OK, so the problem is that exceptions were marshalled/unmarshalled as a special case, and the marshalling included only the stack trace and error message.
This was done to improve performance of RPCs. However, as exceptions are not thrown frequently, I'll remove the TYPE_EXCEPTION type again and marshall exceptions as Serializable.
> JGRP000225: failed unmarshalling buffer into return value
> ---------------------------------------------------------
>
> Key: JGRP-2263
> URL: https://issues.jboss.org/browse/JGRP-2263
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.11
> Environment: jdk1.8.0_66.jdk
> osx 10.10 & ubuntu 17.10
> Reporter: rama rama
> Assignee: Bela Ban
> Fix For: 4.0.12
>
> Attachments: SimpleChat.java
>
>
> trying to send a class that previous work with 3.x return
> "failed unmarshalling buffer into return value"
> jgroups instance it's configured with the default settings
> i create a test case to reproduce it, executing this class on my 2 boxes return
> ----
> GRAVE: JGRP000225: failed unmarshalling buffer into return value
> java.lang.InstantiationException: com.eg.util.comm.SimpleChat$EError
> at java.lang.Class.newInstance(Class.java:427)
> at org.jgroups.util.Util.readException(Util.java:899)
> at org.jgroups.util.Util.exceptionFromStream(Util.java:843)
> at org.jgroups.util.Util.exceptionFromStream(Util.java:831)
> at org.jgroups.util.Util.objectFromStream(Util.java:782)
> at org.jgroups.util.Util.objectFromStream(Util.java:742)
> at org.jgroups.blocks.RequestCorrelator.replyFromBuffer(RequestCorrelator.java:463)
> at org.jgroups.blocks.RequestCorrelator.handleResponse(RequestCorrelator.java:408)
> at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:363)
> at org.jgroups.blocks.RequestCorrelator.receiveMessageBatch(RequestCorrelator.java:326)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:589)
> at org.jgroups.JChannel.up(JChannel.java:837)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:896)
> at org.jgroups.stack.Protocol.up(Protocol.java:372)
> at org.jgroups.protocols.RSVP.up(RSVP.java:233)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:196)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:416)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:416)
> at org.jgroups.stack.Protocol.up(Protocol.java:372)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:293)
> at org.jgroups.protocols.UNICAST3.deliverBatch(UNICAST3.java:1024)
> at org.jgroups.protocols.UNICAST3.removeAndDeliver(UNICAST3.java:833)
> at org.jgroups.protocols.UNICAST3.handleBatchFromSelf(UNICAST3.java:520)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:435)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:697)
> at org.jgroups.protocols.BARRIER.up(BARRIER.java:195)
> at org.jgroups.stack.Protocol.up(Protocol.java:372)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:212)
> at org.jgroups.stack.Protocol.up(Protocol.java:372)
> at org.jgroups.stack.Protocol.up(Protocol.java:372)
> at org.jgroups.stack.Protocol.up(Protocol.java:372)
> at org.jgroups.protocols.TP.passBatchUp(TP.java:1274)
> at org.jgroups.util.MaxOneThreadPerSender$BatchHandlerLoop.passBatchUp(MaxOneThreadPerSender.java:284)
> at org.jgroups.util.SubmitToThreadPool$BatchHandler.run(SubmitToThreadPool.java:136)
> at org.jgroups.util.MaxOneThreadPerSender$BatchHandlerLoop.run(MaxOneThreadPerSender.java:273)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NoSuchMethodException: com.eg.util.comm.SimpleChat$EError.<init>()
> at java.lang.Class.getConstructor0(Class.java:3082)
> at java.lang.Class.newInstance(Class.java:412)
> ... 37 more
> -----
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (WFLY-10109) [Artemis 2.x upgrade] MDB connected to remote server does not get activated when using discovery group with JGroups
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-10109?page=com.atlassian.jira.plugin... ]
Jeff Mesnil reassigned WFLY-10109:
----------------------------------
Assignee: Martyn Taylor (was: Jeff Mesnil)
> [Artemis 2.x upgrade] MDB connected to remote server does not get activated when using discovery group with JGroups
> --------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10109
> URL: https://issues.jboss.org/browse/WFLY-10109
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
> Attachments: log
>
>
> Sometimes happens that MDB does not start to consume messages from remote server. There are not warning or error messages in log.
> Test Scenario:
> * Start server with deployed InQueue and OutQueue
> * Start 2nd server with configured pooled-connection-factory to connect to 1st server
> * Deploy MDB to 2nd server - mdb is consuming messages from InQueue and sending to OutQueue
> * Start sending messages to InQueue to 1st server
> * Let MDB processing messages from InQueue
> * Start consuming messages from OutQueue from 1st server
> Pass Criteria: There is the same number of sent and received messages
> Actual Result: Sometimes happens that Mdb does not start to consume messages.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (WFLY-10109) [Artemis 2.x upgrade] MDB connected to remote server does not get activated when using discovery group with JGroups
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-10109?page=com.atlassian.jira.plugin... ]
Jeff Mesnil edited comment on WFLY-10109 at 4/24/18 5:46 AM:
-------------------------------------------------------------
I'm assigning this issue to the activemq component as it requires additional log/info from Artemis to be able to track down the race condition
was (Author: jmesnil):
I'm assigning this issue to the activemq component as it requires addition log/info from Artemis to be able to track down the race condition
> [Artemis 2.x upgrade] MDB connected to remote server does not get activated when using discovery group with JGroups
> --------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10109
> URL: https://issues.jboss.org/browse/WFLY-10109
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
> Attachments: log
>
>
> Sometimes happens that MDB does not start to consume messages from remote server. There are not warning or error messages in log.
> Test Scenario:
> * Start server with deployed InQueue and OutQueue
> * Start 2nd server with configured pooled-connection-factory to connect to 1st server
> * Deploy MDB to 2nd server - mdb is consuming messages from InQueue and sending to OutQueue
> * Start sending messages to InQueue to 1st server
> * Let MDB processing messages from InQueue
> * Start consuming messages from OutQueue from 1st server
> Pass Criteria: There is the same number of sent and received messages
> Actual Result: Sometimes happens that Mdb does not start to consume messages.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (WFLY-10109) [Artemis 2.x upgrade] MDB connected to remote server does not get activated when using discovery group with JGroups
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-10109?page=com.atlassian.jira.plugin... ]
Jeff Mesnil updated WFLY-10109:
-------------------------------
Labels: activemq feature-branch-blocker (was: feature-branch-blocker)
> [Artemis 2.x upgrade] MDB connected to remote server does not get activated when using discovery group with JGroups
> --------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10109
> URL: https://issues.jboss.org/browse/WFLY-10109
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
> Attachments: log
>
>
> Sometimes happens that MDB does not start to consume messages from remote server. There are not warning or error messages in log.
> Test Scenario:
> * Start server with deployed InQueue and OutQueue
> * Start 2nd server with configured pooled-connection-factory to connect to 1st server
> * Deploy MDB to 2nd server - mdb is consuming messages from InQueue and sending to OutQueue
> * Start sending messages to InQueue to 1st server
> * Let MDB processing messages from InQueue
> * Start consuming messages from OutQueue from 1st server
> Pass Criteria: There is the same number of sent and received messages
> Actual Result: Sometimes happens that Mdb does not start to consume messages.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (WFLY-10109) [Artemis 2.x upgrade] MDB connected to remote server does not get activated when using discovery group with JGroups
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-10109?page=com.atlassian.jira.plugin... ]
Jeff Mesnil commented on WFLY-10109:
------------------------------------
I'm assigning this issue to the activemq component as it requires addition log/info from Artemis to be able to track down the race condition
> [Artemis 2.x upgrade] MDB connected to remote server does not get activated when using discovery group with JGroups
> --------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10109
> URL: https://issues.jboss.org/browse/WFLY-10109
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
> Attachments: log
>
>
> Sometimes happens that MDB does not start to consume messages from remote server. There are not warning or error messages in log.
> Test Scenario:
> * Start server with deployed InQueue and OutQueue
> * Start 2nd server with configured pooled-connection-factory to connect to 1st server
> * Deploy MDB to 2nd server - mdb is consuming messages from InQueue and sending to OutQueue
> * Start sending messages to InQueue to 1st server
> * Let MDB processing messages from InQueue
> * Start consuming messages from OutQueue from 1st server
> Pass Criteria: There is the same number of sent and received messages
> Actual Result: Sometimes happens that Mdb does not start to consume messages.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months