When I upgraded my Spark client to 2.6.0, I could no longer “accept” fastpath transfers. I get the popup and the accept/reject buttons, but pressing “accept” doesn’t do anything. I tried this on several machines, but none of them could “accept” transfers. Any ideas?
I have checked with OF 3.6.4 and Fastpath 4.10/Webchat 4.0 and this works. Also checked against OF 3.7.0 and Fastpath 4.2.0/Webchat 4.0.2 and this works, too. I think you have an isse with your Fastpath setup.This is not related to 2.6.0. Can you please do a double check and test against 2.5.8 which is available here:http://community.igniterealtime.org/docs/DOC-2183
Walter, could you please take a look to my post http://community.igniterealtime.org/message/212495#212495 here?
It’s somewhat related, although I get the first connection user -> agent, I can’t invite or transfer to another agent, be it in the same workgroup or another.
I’ve tested Openfire 3.6.4 + Fastpath 4.1.0 + Spark 2.5.8 and Openfire 3.7.0 + Fastpath 4.2.0 + Spark 2.6.0 and always have the same problem.
FYI: I am using OF 3.7.0 and Fastpath 4.2.0 and webchat 4.0.2 on linux through https. We are running Spark on Windows. Every previous version of Spark has allowed the transfer. As with stickman, I get the original transfer from the webchat and am able to chat, but when we transfer to another agent, the agent gets the notice, but when s/he clicks “accept”, nothing happens - the notice goes away but the chat window never opens. The transferring agent doesn’t get notice that the new agent has joined.
Per your suggestion, I reverted back to 2.5.8 and the transfer works fine - when the new agent clicks “accept” the chat window opens and the transferring agent gets notice that the new agent has joined. In fact, the transfer works in every previous version of spark (2.6.0 beta 2; 2.6.0.12222, etc.) with no changes to the setup. But it doesn’t in this version. I have tried it with windows 7, windows vista & windows XP with the same results?
Hi Craig
i am not aware of Fastpath specific changes. Since I do not have a test setup, I would need some help from you.
Can you please check, if this version of Spark works? It is build 210.
The next build introduced the only change to fastpath that I could research up to now. That next build 211 is at
Are there any specific informations in the error log regarding the transfer?
I tried both build 210 and 211 - they both work, but when I went back to the 2.6.0 download, it didn’t work again. I’m not sure if it will help, but this is what appeared in the error log:
2011.05.16 15:26:49 Could not route packet
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(Unknown Source)
at org.jivesoftware.openfire.plugin.spark.manager.SparkVersionManager.handleSparkI Q(SparkVersionManager.java:161)
at org.jivesoftware.openfire.plugin.spark.manager.SparkVersionManager.processPacke t(SparkVersionManager.java:105)
at org.jivesoftware.openfire.component.InternalComponentManager$RoutableComponents .process(InternalComponentManager.java:587)
at org.jivesoftware.openfire.spi.RoutingTableImpl.routeToComponent(RoutingTableImp l.java:352)
at org.jivesoftware.openfire.spi.RoutingTableImpl.routePacket(RoutingTableImpl.jav a:237)
at org.jivesoftware.openfire.IQRouter.handle(IQRouter.java:324)
at org.jivesoftware.openfire.IQRouter.route(IQRouter.java:121)
at org.jivesoftware.openfire.spi.PacketRouterImpl.route(PacketRouterImpl.java:76)
at org.jivesoftware.openfire.net.StanzaHandler.processIQ(StanzaHandler.java:337)
at org.jivesoftware.openfire.net.ClientStanzaHandler.processIQ(ClientStanzaHandler .java:93)
at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:302)
at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:194)
at org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandl er.java:169)
at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived (AbstractIoFilterChain.java:570)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:299)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:53)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:648)
at org.apache.mina.common.IoFilterAdapter.messageReceived(IoFilterAdapter.java:80)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:299)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:53)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:648)
at org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush(SimplePr otocolDecoderOutput.java:58)
at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecF ilter.java:185)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:299)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:53)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:648)
at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java :239)
at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(Execut orFilter.java:283)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)
at java.lang.Thread.run(Unknown Source)
Hi Craig,
that was fast. This is getting cumbesome, but we have to find the build that screws the transfer. The release build was 298. Between 211 and 298 the bug was introduced. Can you track this down by testing the builds by installing the artefacts from the links:
http://bamboo.igniterealtime.org/browse/SPARK-INSTALL4J-211/artifact/Install4j/
You have to exchange the 211 against a build number between 211 and 298. I suggest to us the “half distance approach”. Start with 254 and move to 273 or 232 depending if the bug is there (move o 232) or not there (move to 273). Sorry that’s a lot of work, but the only way to go. I’ll try to reproduce the problem tomorrow with a student.
I would expect the cause to be related to some work by Wolf on the conference services in builds 220-221, 248, 266-267
Sorry for the delay, I was out most of last week. Build 246 works, build 247 doesn’t. Let me know if you need anything else.
Many thanks for the investigation. I’ll asked Wolf to review his changes in 247.
changes are minimal, the possibility of them breaking anything is less than 5%
the errorlog is not helping, we need spark errorlogs, not openfire
Other than an update error (see below), which I have gotten with all the builds, I have no errors on the agent side who is trying to accept the transfer (when nothing appears) as follows:
May 24, 2011 7:35:41 AM org.jivesoftware.spark.util.log.Log error
SEVERE: There was an error while checking for a new update.
java.lang.ClassCastException: org.jivesoftware.smack.util.PacketParserUtils$2 cannot be cast to org.jivesoftware.sparkimpl.updater.SparkVersion
at org.jivesoftware.sparkimpl.updater.CheckUpdates.getLatestVersion(CheckUpdates.j ava:564)
at org.jivesoftware.sparkimpl.updater.CheckUpdates.newBuildAvailable(CheckUpdates. java:107)
at org.jivesoftware.sparkimpl.updater.CheckUpdates.checkForUpdate(CheckUpdates.jav a:410)
at org.jivesoftware.MainWindow$12.finished(MainWindow.java:664)
at org.jivesoftware.spark.util.SwingWorker$2$1.run(SwingWorker.java:148)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
On the original webchat agent side (the one trying to transfer), when they click “transfer”, they get the "waiting for . . . to accept this transfer. But, of course, when the agent it is being transferred to clicks “Accept”, nothing happens on either side. Just to make it clear, the original agent can always get the request for chat from the webchat, it is only upon trying to transfer to another agent that breaks between build 246 and 247. I might also add that I have not kept changing the version of the person trying to transfer, just the version on the person trying to accept the transfer.
There is an error on the agent side trying to transfer, but I’m not sure it is related, but I will put it here if you think it will help:
May 24, 2011 7:39:10 AM org.jivesoftware.spark.util.log.Log error
SEVERE:
No response from server on status set.:
at org.jivesoftware.smackx.workgroup.agent.AgentSession.setStatus(AgentSession.jav a:426)
at org.jivesoftware.fastpath.workspace.Workpane$PresenceChangeListener.presenceCha nged(Workpane.java:841)
at org.jivesoftware.spark.SessionManager.changePresence(SessionManager.java:190)
at org.jivesoftware.spark.ui.status.StatusBar$5$1.construct(StatusBar.java:217)
at org.jivesoftware.spark.util.SwingWorker$2.run(SwingWorker.java:141)
at java.lang.Thread.run(Unknown Source)
Hope that helps? If I am the only one having problems, it could be my setup, but strange that it used to work, but now doesn’t??? Whatever you can do to help resolve it would be great though . . . .
With respect to your question, if you are the only one… Fastpath transfer is working for me on 3.6.4 and 3.7.0. There is an issue of multiple transfers, but that is a different story.
FYI: I downloaded a newer build just as a test and the newest build works for me so I will just revert back to the older version and wait for the next release and hope for the best
FYI: I just wanted post an update that my issue with FastPath and Spark 2.6.0 is gone with the newest version of Spark (2.6.3). The transfers are working just fine! Thanks for those who tried to help and for all the work you all do on Spark!