[JBoss JIRA] (WFLY-5785) EJB lookup fails with "No cluster context available" in failover tests
by Dominik Pospisil (JIRA)
[ https://issues.jboss.org/browse/WFLY-5785?page=com.atlassian.jira.plugin.... ]
Dominik Pospisil reassigned WFLY-5785:
--------------------------------------
Assignee: Dominik Pospisil (was: Richard Achmatowicz)
> EJB lookup fails with "No cluster context available" in failover tests
> ----------------------------------------------------------------------
>
> Key: WFLY-5785
> URL: https://issues.jboss.org/browse/WFLY-5785
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR5
> Reporter: Michal Vinkler
> Assignee: Dominik Pospisil
>
> Seen in our failover tests for remote stateful EJBs - scenarios:
> ejb-ejbremote-shutdown-dist-async
> ejb-ejbremote-shutdown-dist-sync
> ejb-ejbremote-undeploy-dist-async
> After failing a node, occasionally EJB lookup starts failing - client starts logging these error messages:
> {code}
> 2015/12/03 04:46:47:078 EST [ERROR][Runner - 9] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error getting response. <java.lang.IllegalStateException: EJBCLIENT000029: No cluster context available for cluster named ejb>
> java.lang.IllegalStateException: EJBCLIENT000029: No cluster context available for cluster named ejb
> at org.jboss.ejb.client.EJBClientContext.requireClusterEJBReceiverContext(EJBClientContext.java:1063)
> at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:84)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:255)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:200)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> at com.sun.proxy.$Proxy2.getSerialAndIncrement(Unknown Source)
> at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.processRequest(StatefulSBProcessorFactoryImpl.java:84)
> at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52)
> at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:103)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> It stops logging these messages only after the failed node is restarted and joins the cluster again.
> Link (this job was configured to use only 100 sessions in order to keep the log size small)
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-7x-failo...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (JGRP-1989) Bundlers: reuse send buffer when transport == sync.
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/JGRP-1989?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on JGRP-1989:
------------------------------------
[~sannegrinovero] I don't agree that most of the messages are large (or that the size is predictable at all). In Infinispan, we send *a lot* of small messages, e.g. a remote get command only contains a small key, or the response might be just a few bytes to indicate the operation is successful.
> Bundlers: reuse send buffer when transport == sync.
> ---------------------------------------------------
>
> Key: JGRP-1989
> URL: https://issues.jboss.org/browse/JGRP-1989
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> With the addition of {{TCP_NIO2}}, all bundlers now create new send buffers for every message (or message list). This generates a lot of memory allocations, perhaps it is better to revert this change for *synchronous transports* such as {{UDP}} and {{TCP}}, and still create new buffers for *asynchronous transports* such as {{TCP_NIO2}}.
> Synchronous transports guarantee a message has been put on the wire when {{TP.send()}} returns, whereas asynchronous transports may only have completed a partial write (so we cannot reuse the buffer).
> The code in the bundler should check for this, and copy if async or not copy if sync.
> Whether or not a transport is sync is determined by a new abstract method that needs to be overridden by every transport.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (JBMESSAGING-1958) Backward compatibility issue caused by recent fixes
by Yong Hao Gao (JIRA)
[ https://issues.jboss.org/browse/JBMESSAGING-1958?page=com.atlassian.jira.... ]
Yong Hao Gao commented on JBMESSAGING-1958:
-------------------------------------------
JBMESSAGING-1851 was fixed in releases 1.4.0.sp3_cp12 (incremental version 43) and 1.4.8.GA (incremental version 44)
JBMESSAGING-1876 was fixed in releases 1.4.0.sp3_cp13 (incremental version 46) and 1.4.8.GA.SP1 (incremental version 45)
so the fix would be to write the new fields into the wire when the client version matches the above corresponding versions.
i.e.
if (clientVersion > 42)
{
out.writeLong(this.maxRetryChangeRate);
out.writeLong(this.retryChangeRateInterval);
}
if (clientVersion > 44)
{
out.writeLong(this.minTimeoutProcessTime);
}
> Backward compatibility issue caused by recent fixes
> ---------------------------------------------------
>
> Key: JBMESSAGING-1958
> URL: https://issues.jboss.org/browse/JBMESSAGING-1958
> Project: JBoss Messaging
> Issue Type: Bug
> Components: JMS Remoting
> Affects Versions: 1.4.0.SP3.CP14, 1.4.8.SP11
> Reporter: Yong Hao Gao
> Assignee: Yong Hao Gao
> Fix For: 1.4.0.SP3.CP15, 1.4.8.SP12
>
>
> In the following Jiras:
> https://issues.jboss.org/browse/JBMESSAGING-1851
> https://issues.jboss.org/browse/JBMESSAGING-1876
> We've added three more fields in ClientConnectionFactoryDelegate
> private long maxRetryChangeRate;
> private long retryChangeRateInterval;
> private long minTimeoutProcessTime;
> This will cause backward compatibility issues when JBM server talks to old clients that are not aware of those changes. To those old clients the three fields are marshalled but never read by client. This will cause marshal problems as shown in the following example stack trace:
> 20:08:46,052 INFO [MicroSocketClientInvoker] SocketClientInvoker[47f6473, bisocket://127.0.0.2:4457] got exception java.io.IOException
> 20:08:46,054 ERROR [SocketClientInvoker] Got marshalling exception, exiting
> java.io.IOException
> at java.io.DataInputStream.readFully(DataInputStream.java:197)
> at java.io.DataInputStream.readUTF(DataInputStream.java:609)
> at java.io.DataInputStream.readUTF(DataInputStream.java:564)
> at org.jboss.messaging.util.Version.read(Version.java:251)
> at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.read(ClientConnectionFactoryDelegate.java:348)
> at org.jboss.jms.delegate.TopologyResult.read(TopologyResult.java:123)
> at org.jboss.jms.wireformat.ConnectionFactoryGetTopologyResponse.read(ConnectionFactoryGetTopologyResponse.java:70)
> at org.jboss.jms.wireformat.JMSWireFormat.read(JMSWireFormat.java:303)
> at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:917)
> at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:603)
> at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:422)
> at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:141)
> at org.jboss.remoting.Client.invoke(Client.java:1858)
> at org.jboss.remoting.Client.invoke(Client.java:718)
> at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate.org$jboss$jms$client$delegate$ClientClusteredConnectionFactoryDelegate$getTopology$aop(ClientClusteredConnectionFactoryDelegate.java:326)
> at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate.getTopology(ClientClusteredConnectionFactoryDelegate.java)
> at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate.establishCallback(ClientClusteredConnectionFactoryDelegate.java:105)
> at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate.readObject(ClientClusteredConnectionFactoryDelegate.java:84)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1017)
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1896)
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1801)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1351)
> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1993)
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1918)
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1801)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1351)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:371)
> at java.rmi.MarshalledObject.get(MarshalledObject.java:160)
> at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:72)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:737)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:654)
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> at org.jms.client.JMSClient.getFactory(JMSClient.java:147)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5862) Update Javax.mail to 1.5.5
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5862?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-5862:
------------------------------
Description:
CHANGES IN THE 1.5.5 RELEASE
----------------------------
The following bugs have been fixed in the 1.5.5 release.
K 6886 add support for setting GMail labels on messages
K 6905 Add spam filter for use with MailHandler.
K 6907 Address MailDateFormat issues
K 6938 Typo in "mail.stmp.sendpartial"
K 6943 mail.mime.encodefilename property should override RFC 2231 encoding
K 6964 IMAP should support a mail.imap.auth.mechanisms property like SMTP
K 6965 setting mail..auth.mechanisms should override
mail..auth..disable
K 6966 add support for OAuth 2.0 without SASL
K 6973 capability() command doesn't properly transform errors
K 6989 MailHandler needs better support for stateful filters.
K 6997 add support for IMAP login referrals (RFC 2221)
K 7009 whitespace line at beginning confuses InternetHeaders
K 7014 IndexOutOfBoundsException reading IMAP literal when connection fails
K 7019 IdleManager dies with CancelledKeyException
K 7026 IdleManager can deadlock when not busy
K 7027 IMAP Folder methods throw runtime exceptions when connection drops
K 7028 InternetAddress doesn't detect some illegal newlines
K 7030 Status class doesn't decode mailbox name
K 7035 add support for IMAP COMPRESS extension (RFC 4978)
K 7052 Empty Gmail X-GM-LABELS list is misparsed
K 7075 IMAPMessage.getReceivedDate should check if receivedDate is present
before loading envelope
K 7083 CollectorFormatter descending order data race
K 7090 off-by-1 error in Response.readStringList causes early termination of
parsing FETCH response
K 7094 INTERNALDATE FetchProfile Item
K 7104 Exchange returns NIL instead of "" for empty parameter, causing NPE
CHANGES IN THE 1.5.4 RELEASE
----------------------------
The following bugs have been fixed in the 1.5.4 release.
K 6719 Include elapsed time, thread id, and sequence for logging formatters.
K 6767 MailHandlerTest does not check field is static or final
K 6804 IdleManager can deadlock with frequent notifications
K 6817 IdleManager can deadlock when connection fails
K 6824 IMAP provider should support the MOVE extension (RFC 6851)
K 6840 MODSEQ should be stored in IMAPMessage if CONDSTORE is enabled
K 6844 Space character lost from end of quoted-printable body parts
K 6850 GmailMessage extensions are not cached after implicit FETCH
K 6852 IMAP message sets should be sorted in cases where order doesn't matter
K 6860 ID command shouldn't escape NIL value
K 6863 Make IMAPProtocol class extendable
> Update Javax.mail to 1.5.5
> --------------------------
>
> Key: WFLY-5862
> URL: https://issues.jboss.org/browse/WFLY-5862
> Project: WildFly
> Issue Type: Component Upgrade
> Components: EE, Mail
> Affects Versions: 10.0.0.CR4
> Reporter: Erick de Oliveira Leal
> Assignee: Tomaz Cerar
> Priority: Minor
>
> CHANGES IN THE 1.5.5 RELEASE
> ----------------------------
> The following bugs have been fixed in the 1.5.5 release.
> K 6886 add support for setting GMail labels on messages
> K 6905 Add spam filter for use with MailHandler.
> K 6907 Address MailDateFormat issues
> K 6938 Typo in "mail.stmp.sendpartial"
> K 6943 mail.mime.encodefilename property should override RFC 2231 encoding
> K 6964 IMAP should support a mail.imap.auth.mechanisms property like SMTP
> K 6965 setting mail..auth.mechanisms should override
> mail..auth..disable
> K 6966 add support for OAuth 2.0 without SASL
> K 6973 capability() command doesn't properly transform errors
> K 6989 MailHandler needs better support for stateful filters.
> K 6997 add support for IMAP login referrals (RFC 2221)
> K 7009 whitespace line at beginning confuses InternetHeaders
> K 7014 IndexOutOfBoundsException reading IMAP literal when connection fails
> K 7019 IdleManager dies with CancelledKeyException
> K 7026 IdleManager can deadlock when not busy
> K 7027 IMAP Folder methods throw runtime exceptions when connection drops
> K 7028 InternetAddress doesn't detect some illegal newlines
> K 7030 Status class doesn't decode mailbox name
> K 7035 add support for IMAP COMPRESS extension (RFC 4978)
> K 7052 Empty Gmail X-GM-LABELS list is misparsed
> K 7075 IMAPMessage.getReceivedDate should check if receivedDate is present
> before loading envelope
> K 7083 CollectorFormatter descending order data race
> K 7090 off-by-1 error in Response.readStringList causes early termination of
> parsing FETCH response
> K 7094 INTERNALDATE FetchProfile Item
> K 7104 Exchange returns NIL instead of "" for empty parameter, causing NPE
> CHANGES IN THE 1.5.4 RELEASE
> ----------------------------
> The following bugs have been fixed in the 1.5.4 release.
> K 6719 Include elapsed time, thread id, and sequence for logging formatters.
> K 6767 MailHandlerTest does not check field is static or final
> K 6804 IdleManager can deadlock with frequent notifications
> K 6817 IdleManager can deadlock when connection fails
> K 6824 IMAP provider should support the MOVE extension (RFC 6851)
> K 6840 MODSEQ should be stored in IMAPMessage if CONDSTORE is enabled
> K 6844 Space character lost from end of quoted-printable body parts
> K 6850 GmailMessage extensions are not cached after implicit FETCH
> K 6852 IMAP message sets should be sorted in cases where order doesn't matter
> K 6860 ID command shouldn't escape NIL value
> K 6863 Make IMAPProtocol class extendable
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-459) javassist should also be exported to Hibernate (native) applications
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-459?page=com.atlassian.jira.plugin.s... ]
Scott Marlow commented on WFLY-459:
-----------------------------------
[http://pastebin.com/H3tFTH86] + [http://pastebin.com/1cB1aVvB] are some examples.
> javassist should also be exported to Hibernate (native) applications
> --------------------------------------------------------------------
>
> Key: WFLY-459
> URL: https://issues.jboss.org/browse/WFLY-459
> Project: WildFly
> Issue Type: Task
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Fix For: 10.0.0.CR5
>
>
> Originally this jira was to stop exporting the javassist module to JPA deployments but it turns out that is fine to do. In addition, native Hibernate applications that depend on Hibernate, should also get the javassist dependency.
> # native Hibernate applications will get the javassist dependency via the application dependency on org.hibernate.
> # container managed JPA applications will get the javassist dependency via org.jboss.as.jpa.processor.JPADependencyProcessor (JPA deployer).
> # container managed JPA applications that embed their own copy of Hibernate jars will also get the javassist dependency via org.jboss.as.jpa.processor.JPADependencyProcessor (JPA deployer).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
