I'm trying to copy messages from one IMAP store to another.
The line of code that does the actual copying is:
folder.appendMessages(new Message[] { m });
Most messages are copied with no problem, but some fail with:
javax.mail.MessagingException: IOException while appending messages;
nested exception is:
java.io.IOException: No content
The stacktrace points to IMAPFolder.java:1767
Some of the messages that were copied successfully were as large as 6MB, while some of the ones that failed were as small as 16KB in my test case, so it is not a size issue.
I'm not certain, but it's possible that the messages that fail has an attachment. The content type multipart/ALTERNATIVE was found in both in the group of messages that failed and the group that succeeded.
Opening the failed messages in a mail client like Thunderbird works properly, so the messages are not corrupted.
UPDATE:
mail.imap.fetchsize plays a role with this problem. When it is the default of 16,384b, running over a sample of 1000 messages the smallest failed message is 16,432b -- slightly over the fetchsize.
When I increased it to 65,536b -- the smallest failed message of that same sample is 65,787b -- slightly over the fetchsize again.
The message with size 16,432b that consistently failed with the default fetchsize, copied successfully with the higher fetchsize, so this is definitely an issue here.
Any idea what causes this problem?
How can I copy the messages with having this issue?
TIA!
p.s. I'm using Java 1.7u71 and Javamail 1.5.2
Based on our offline discussion, setting the mail.imap.partialfetch property to false causes it to work. When that happens, it's almost always because the server is broken in some way.
See also:
Javamail Notes under "A list of the known limitations, bugs, issues" sections 4 and 5.
Javamail FAQ, Fetch
The bug was fixed in Java Mail 1.6
https://javaee.github.io/javamail/
Related
I am upgrading a standalone Java app that uses IBM MQ to send messages to a local Websphere 8.5 server. The existing app uses a bunch of different jars for the MQ code (mq, mqbind mqjms, connector-api, jms).
For the new one I saw that there is now an all-encompassing "allclient" MQ JAR (https://mvnrepository.com/artifact/com.ibm.mq/com.ibm.mq.allclient/9.2.0.0) so I decided to use that.
It appears to work just fine for the first few messages, but after sending 4-5 messages, all subsequent messages will then fail with a code 2594 (https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.1.0/com.ibm.mq.tro.doc/q120510_.htm):
Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2594;AMQ9204: Connection to host 'localhost(5558)' rejected. [1=com.ibm.mq.jmqi.JmqiException[CC=2;RC=2594;AMQ9503: Channel negotiation failed. [3=WAS.JMS.SVRCONN ]],3=localhost(5558),5=RemoteConnection.initSess]
at com.ibm.mq.jmqi.remote.api.RemoteFAP$Connector.jmqiConnect(RemoteFAP.java:13588)
at com.ibm.mq.jmqi.remote.api.RemoteFAP$Connector.access$100(RemoteFAP.java:13125)
at com.ibm.mq.jmqi.remote.api.RemoteFAP.jmqiConnect(RemoteFAP.java:1430)
at com.ibm.mq.jmqi.remote.api.RemoteFAP.jmqiConnect(RemoteFAP.java:1389)
at com.ibm.mq.ese.jmqi.InterceptedJmqiImpl.jmqiConnect(InterceptedJmqiImpl.java:377)
at com.ibm.mq.ese.jmqi.ESEJMQI.jmqiConnect(ESEJMQI.java:562)
at com.ibm.mq.MQSESSION.MQCONNX_j(MQSESSION.java:916)
at com.ibm.mq.MQManagedConnectionJ11.<init>(MQManagedConnectionJ11.java:240)
On the server side, I get the following in the console:
CWSIC3712E: A WebSphere MQ client, previously connected from host 127.0.0.1:58963 on transport chain InboundBasicMQLink, has been disconnected because of exception java.io.IOException: Async IO operation failed (1), reason: RC: 55 The specified network resource or device is no longer available.
After this error occurs, any subsequent attempts to send a message will fail with the same error. I have to restart the app at which point the same thing repeats: first 4-5 messages send before the fails begin. If I switch back to using the old JARs without changing the code, I'm able to send an unlimited number of messages without any issues.
The reason code is confusing to me ("An MQCONN or MQCONNX call was issued from a client connected application, but it failed to agree a password protection algorithm with the queue manager.") because if it's truly a password issue, why do the first couple messages send without issue? It does not seem to be an issue with closing/disconnecting the queue/manager because I'll wait a few seconds between each send and can breakpoint/println and see that each time they are being closed before the next send.
Any ideas?
I found a partial workaround to this problem:
In the Java code, for our MQMessage object, we declare a "replyToQueueName". If I remove that setter, the problem seems to go away (we can send as many messages as we want without error).
I'm not certain why in this particular case that seems to work. The failure that occurs happens on the MQQueueManager declaration which is much higher up in the code than the replyToQueueName setter. This combined with this bug only occurring after 4-5 messages are sent seems to maybe indicate that something is not being "closed" properly but as far as I know there is no way to "close" a message and we are already closing/disconnecting the manager and the queue.
I am getting exception "The message store has reached EOF" when I try to connect to remote host for SFTP using "com.enterprisedt.net.ftp.ssh.SSHFTPClient" class (edtFTPj/PRO - a commercial Java file transfer client).
I am able to successfully connect to another remote host for SFTP with the same code.
Is there any configuration specific to the particular host which is causing the problem? If that is the case, is there any way to confirm it? I don't have any other log other than this exception message. However, I can change the code to try any suggested debugging options.
Please note that I can't use other SFTP library as my existing code is already using this library.
com.enterprisedt.net.j2ssh.authentication.AuthenticationProtocolException: Failed to read messages
at com.enterprisedt.net.j2ssh.authentication.AuthenticationProtocolClient.a(AuthenticationProtocolClient.java:265)
Caused by: com.enterprisedt.net.j2ssh.transport.MessageStoreEOFException: The message store has reached EOF
at com.enterprisedt.net.j2ssh.transport.SshMessageStore.getMessage(SshMessageStore.java:177)
at com.enterprisedt.net.j2ssh.transport.SshMessageStore.getMessage(SshMessageStore.java:110)
at com.enterprisedt.net.j2ssh.authentication.AuthenticationProtocolClient.a(AuthenticationProtocolClient.java:261)
... 31 more
I think there is a problem with the library itself. A concurrency problem. I could reproduce this and other random errors consistently when you try to open many connections at the same time (in the same millisecond), for example, when you use multiple threads to do that. This happens even if you use several different SSHFTPClient instances. I think there should be a static thing inside those classes.
I had to synchronize the access of any SSHFTPClient instances using a third variable, like this:
final static String sincronizadorUnico = "";
synchronized (sincronizadorUnico) {
// use the code to connect
}
The it will work. I will report the bug to the library. I'm using 7.1.0 version of library.
I've had no luck finding this issue in any search. I've also posted this question on the Apache forum, but haven't had any luck there so far.
I have an application on a JBoss application server (EAP 6.2) with an Apache 2.2.26 server in front of it acting as a reverse proxy for HTTPS. The application has a large multi-part form which recently has been experiencing an intermittent drop of a single form field from the post data (not always the same field). We've verified that all of the data is being sent, but not being received by the application. The issue does not occur if we HTTP directly to the JBoss server (test server). We've repeatedly sent the same form data and sometimes a single form field is dropped (not always the same field) and sometimes it is not. But, it happens often enough to be easily repeated. The issue happens on Internet Explorer and Firefox, so does not appear to be browser related. The amount of data being sent varies, but is usually in the 10-30 KB range. There aren't any errors appearing in the Apache server log even when logging at the debug level.
One additional bit of information is that since this is a multi-part form, the browser includes a boundary value between each form field and file when submitted. We've noted that the size of this boundary value varies and the form data that is being lost changes depending on the size of the boundary value when the same form data is being sent.
Any ideas as to what might be causing this data loss would be most appreciated.
Update: This issue is similar to an old bug reported for Apache 2.0.55 and 2.2.2, link
Update: Found out how to monitor the number of bytes received at the JBoss ajp port. The same number of bytes being sent from the browser are arriving at the ajp port. Could this be a chunk encoding issue?
It turned out that this issue had something to do with the SLL protocol. We were using TLSv1 and recently changed to TLSv1.2. The problem went away with the protocol upgrade. So, we changed back to TLSv1 in a test environment. The problem reappeared. We then changed to TLSv1.2 and the problem went away.
No idea why the protocol change fixed the issue, but I do know that considerable changes were made TLSv1.2 . At this point just glad the protocol upgrade resolved the issue.
I have configured hornetq for handling large messages but large message directory becomes too large if client is not up ,consuming whole disk space
Plz help to figure out how to delete or clean large message folder after message been delivered ?
also paging directory not being created in jboss/server/default/data/hornetq.
The messages should be removed after consumed.
If they are filling up it means your clients are not acking the messages.
What version are you using? I would also update the versions as we have fixed a few bugs around large message deliver.
Stop the instance and clear all the messaginglargemessages and messagingjournal then start the instance again.
I have a setup in which some applications communicate with each other via Tibco rendezvous. The applications communicate using certified messaging. My problem is that two of my receivers have recently started exhibiting the behavior that they will get an Error 27, Not Permitted when they want to confirm a message (the first message in a certified message exchange isn't certified, we've accounted for that).
I've been looking around the internet to find people with the same error, and I have found many, but they all get the error when trying to create the tibco transport. I can create the transport just fine, but I can't confirm any messages received over it.
Our environment uses both tibco 7.X and 8.X, some times intermingled. This problem appears both when the peers use the same tibco version and when they use different versions. It doesn't show up for all applications, but when it does show up for an application, it remains "broken". Discarding the ledger files for both sender and receiver does nothing. We still get the error. Both sender and receiver have proper permissions to write to (and create the) ledger files. We are connecting to permanently running rvds. The sender and receiver are on different machines. Communication has worked flawlessly in the past, but at some point, it stopped doing so. The application is in java, and we're using the tibrvj.jar auto-native libraries.
The error is
...
Caused by: TibrvException[error=27,message=Not permitted]
at com.tibco.tibrv.TibrvImplCmTPortC.natConfirmMsg(Native Method)
at com.tibco.tibrv.TibrvImplCmTPortC.confirmMsg(TibrvImplCmTPortC.java:304)
at com.tibco.tibrv.TibrvCmListener.confirmMsg(TibrvCmListener.java:88)
....
I know you're going to ask me "what did you do to make it start happening", and my response is "I don't know".
Any input would be appreciated.
Thanks.
It may be possible that TCP connections between the two RVD servers is not possible. Can you check if you can connect from one to the other (connect from the subscriber host back to the publisher)? In my experience, CM acknowledgments are handled over TCP (please take this with a grain of salt as I'm more an end user than a Middleware support guy).
As it turns out, it was a screw-up on the application level.
Due to some old code lying around, after having updated a dependency (our messaging layer), we had moved from an application level confirmation to a container level confirmation, but we had forgotten to remove an explicit message confirmation in the application code.
To summarize: We tried to confirm the message twice, and the second time it threw this exception.
I recently encountered the same exception - application had been working for months, suddenly was throwing exception. In my case some maintenance had been done on the Windows server the application ran on and directories had been marked read-only. Once that was cleared the exception went away.
Discovered this after trouble-shooting hours worth of other potential causes.
Just my two cents: This exception also occurs when you try to explicitly confirm message on non-CM transport.